All Core Devs - Execution #18

Transcript

[Music] [Music] [Music] [Music]

[Music] d [Music] [Music] n [Music]

[Music] [Music] uh yes am I coming through [Music] okay [Music]

[Music] [Music] hello [Music] [Music]

[Music] [Music]

can [Music] excellent [Music] yep

hey vitalic can you hear me oh you're on mute metalic on Hangouts yes I can hear you Hudson perfect uh Robert can you hear me yes I can excellent uh Andre yes I can hear you I'm here with Yi hi hello awesome all right I think we can get started so MH let's see oh I'm on the wrong agenda

here we go see I put a link to the agenda in the chat I also put a link to the troll boox and the first item is EIP 206 uh the revert op code uh yoichi had a question about it so yoichi you can uh go ahead with that what oh sorry probably should more specific can you this for the moment I have to remember about oh yeah no problem uh Jeff uh you had a question over the atomicity of uh ecda accounts on uh EIP 208 for transaction and

signature abstraction uh yeah that's correct uh so the the the issue here I think it's easiest to understand uh in the context of uh for example ecdsa accounts right now trying to use ens um M so basically the fact that uh ecdsa accounts can only do uh one operation at a time means that they can't do something like look up a name and then do a transaction to the the address it resolves to or something like that um and uh obviously if we move to contract based uh a new a new contract for ecdsa then that would potentially have the ability to perform multiple operations uh

atomically um so then my question was mainly about do we expect everyone in ecds say to move over to contract based accounts is that kind of the plan or if not do we need to to deal with the atomicity issue some other way I would so my personal preference would be that in the long term we should move everyone into uh into e86 contracts but realistically speaking I do think that if we're going to make the transition compulsory that's something that we should do slowly and carefully um and if it loses back compatibility possibly over a fairly long duration um

so it's like in the long term personally I Bas I do feel like making every account be contract based is better because like it reduces the number of classes of things that the protocol has to has to be able to deal with um but basically there's a couple of challenges so one of them is that if we want to make some kind of compulsory transition then we might still have to keep the old ad the uh well actually no it's not it's not really a problem to keep the old the old addressing scheme because we can just like swap the code over uh in place for

something that's uh that basically does the exact same thing I guess the main challenge would be that as you as you said in your post that it would break tx. origin right and I I just saw your reply about uh asking for a concrete use case uh and I have one um about uh the issue with tx. origin so uh right now tx. origin is the only way to uh attribute uh the difference between um who published a response in a state Channel and who signed a response um and uh since we expect uh there to be like third party transaction publishing services for State channels then it's actually quite an important

role at present and why do you wants to know in protocol who published the year response uh basically so that you can um on the one hand uh pay uh uh rewards and bounties for people who published transactions for you while you weren't available or online um and on the other side uh so that you can um uh differentiate between um uh like a like a publicly claimed um Bounty where anyone might be actually publishing the transaction um versus uh um something that's just coming in

through a forwarding contract so um like right now the way that you accept signed messages from strangers this might be different um post Metropolis but U the way that you submit the signed messages of strangers is that you you need to set up a ecdsa validating forwarding contract that's a member of say the multisig that controls the channel so uh it's TX origin is really the only way to identify who's submitting the message because you're using the forwarding contract as the validation of ownership so you're already using message. sender okay and okay so that case I guess there's

two so with tx. origin right there's two there's two things that we could possibly do where one of them is to basically do nothing and let the op code deprecate itself and the other is that we do this change where if tx. Center is the null Center then we basically switch tx. origin to being the tx.2 account and I think I may have mentioned that like personally speaking I am happy with both and if we decide that there is enough value in uh letting people know who the origin is then i' be what we happy taking that road so I think setting it to the two account isn't quite enough if you have contracts which would manage multiple accounts like you know verifying some

other signature scheme but you know anybody create it and counting that contract rather you just have the contract be able to set tx. origin as it prefers but only if it's the first call in the chain to do that so you could um so if you're talk if the goal that you're trying to meet is to have a different is to be able to have generic contracts for verifying specific signature algorithms then you probably do not want to have a workflow that says like null sender calls a signature of your fire signature verifier calls the account you probably want null sender calls the account then the account calls the signature verifier the signature verifier replies zero or on in the

account so then the account doesn't stay and the rationale for that would be that on the one hand um you would uh have um what was um so on the one hand you it would be cleaner from a tx. origin perspective and on the other hand you would also be able to use the signature vrire for applications other than being the single signature V fire inside for a forwarding contract so like one example is that if let's say that we have a contract in a library whose purpose is to be let's say a Lampard signature verifier now let's say I want to have an

account and I want that accounts to be a two of three multi multi of Lamport signatures then that's something that if we just signature make signature verifiers just like the libraries that were zero or one that could could just be constructed very easily because you just like call the Lamport signature vfire three times whereas if you made it be if you made it follow this kind of forwarding pattern where like null sender calls Anri fire or calls the account so that would be harder to compose sure yeah I think that that makes sense but speaking strictly from a flexibility perspective uh I'd rather not set it up in a way that shoehorns us into one mode of implementation

um so so the other challenge with allowing if you actually allow it to set TX out origin is that that's a security loophole right because a malicious contract can set a weird TX at origin that doesn't belong to it I mean I think you could say that like you could have an OB code that sets the tx. origin value to the message sender only if the TX that origin has not yet been set but look that just seems weird and I'm not convinced that the the extra complexity is worth worth it over just like a simple and first check the TX Center and if not check T check the TX destination so I'm sorry I I uh didn't

read up on this exact use case for State channels but it sounded like what you it sound like you don't necessarily want to have tx. origin but more like MSD do Center of minus two or something like that so two levels up in the call chain or am I wrong there uh at present it's txor that actually that you want you don't need to go one more level in the call chain and I think even if we switch to contract accounts it be it would just be the the minus one not two levels deep I mean what about what about so what I so what we previously also discussed about TX origin is uh in the presence of callbacks may it be via some

Oracle or a cross Shard call or something like that um then tx. origin is actually actually not the person who published something but TX origin is just the service that did the call back would that still work for your use case uh yeah that that could potentially be okay um I I think you you could plan around that sharding will require some planning around uh that sort of thing anyways I think go ahead would there be a workaround where this uh the account that current is currently is TX origin has to call into the state Channel

rewarding contract whatever to uh set their address and then uh it is uh the it is identified in that way would that work as a work around um it doesn't work the the way you describe because um the state channels don't look like State channels uh they just look like multi and the other random people who are publishing messages aren't members of them so they don't have any there is no place for them to call there is nothing for them to register you could set up a separate registry where they they they claim it and then it sort of I guess it would have to like automically reset every time or I don't know there could be some kind of weird workaround uh and it ALS it definitely doesn't work if you don't

have atomicity um like at present definitely it's impossible to do without tx. origin but if we have atomicity where you can have multiple operations inside of the same externally signed transaction then you might be able to to build a workr I see okay one thing that I can say about uh tx. origin uh is that it's nice sometimes for it to be the person who's paying the gas um if I've seen a pro like protocols where you want to refund whoever's paying the gas and if like we lose the property that tx. orig is the person paying the gas um then that might not be that nice but for abstracted contract

that's not necessarily uh the case anymore right if we could have uh how how are the this called R call style contracts where some some other person pays for the gas not the the uh the initial the the TX origin contract so do you want a tx. gas pair is there a well-defined single gas pair not necessarily um that could be could be rough in the context of something like a mandatory gas price policy yeah and it could also be rough in the context of weird stuff where one guy pays for gas and like in maker Quinn and the other guy compensates him in

like ether Doge yeah so that's actually kind of why I want there to be a tx. gaspay kind of thing I'm getting the kind of sound that maybe there's better abstraction for what you guys want and need that is not TX but origin but it's something which is better suited for those purposes but less likely to been abused like J origin for authority so the situation I'm describing isn't

using TX out origin for Authority it's just using it for uh identifying who the original uh uh like who kicked off the chain of events basically yeah yeah say paying for gas is the the first good use case I've heard of for tx. [Music] origin uh Nick didn't you do some just basic scanning of the network to see who's using tx. orig uh or was that for something else uh that was something else that was me trying to scan for things that tried to read past the end of call data that's right okay never mind then that would be

a useful thing to do though um and it would actually be a lot simpler than the call out thing okay so there's a number of issues on EIP 208 so what we can do is um it sounds like we actually have found a use case for it in this in that case so if you could maybe um well actually I don't know would it be worth it for Nick to run something like that to see just how inuse it is I guess that could help determine if a different abstraction should be created in transaction origin then deprecated as long as it's not in wide use informally I'm fairly sure nobody's using it much to pay for G because the issue is that the caller can can grief

You by seeing a very high gas price um but I agree that Gathering data is is probably a good idea and I have been meaning to build some better stat stuff for a while but I am kind of absurdly busy and I'm not sure that fella could be very happy if I took time off doing garbage collection in order to collect stats on tx. Origin yeah I mean it's just yeah whatever the priorities are so um yeah okay cool so I think that hm anyone else have comments on that so please go ahead yeah I just have a question about gas price and account abstraction um is it going to be

possible to have different gas prices on different legs of the ex of of an execution of a transaction um so it's theoretically possible for accounts to pay the minor whatever they want if the minor is willing to accept it so like you could potentially have an account that has some weird policy where it charges where it pays like 20 Shannon per gas in the outer call and then 10 Shannon for everything in the inner call but I expect that miners would would prefer to just accept transactions with uniform gas policies basically because their incentives are primarily structured by the uniform gas limit and obviously the uniform Uncle risk or the kind of largely uniform

risk a gas price in the transactions anymore except for kind of oldale transactions yeah no so like e86 transactions have a gas price but it's basically the stigle or at least the the gas price that the protocol is aware of is basically the sigil Christian did you have a comment uh yes so I mean I was just thinking about whether there's there might be a way might be a solution where we delay the solution in some way like for

example throw when someone uses TX origin inside a transaction that is initiated from uh from an uh new sty transaction or something like that yeah h yeah I mean yeah so like the thing that we could potentially do is we could or or potential the other thing we could do is just like do nothing to TX that origin right now and then just like explicitly say you know we are going to we are probably going to change TX that origin behavior in the future and then whenever we end up doing the next hard Fork that starts making um e or whatever hard Fork starts making transitions to i86 accounts compulsory that's the one where we'll figure out what to do with

the ex origin more properly when you say do nothing you mean it becomes a n CER right yes i' I'd personally be in favor of doing that let T origin be the M sender and then at some point in the future uh address the situation with the legit use case here and that might be tx. gas price gas pay or whatever yeah at the moment though it doesn't seem like we have any kind of infrastructure to tell really who's paying gas um in some way if if the abstraction

really just lets miners kind of arbitrarily decide take compensation well to be fair there's no such things an abstraction layer that doesn't let miners arbitrarily take compensation yeah I mean you can you can like make them take at least some amount you well yes but that's like totally diff totally different from not making them take compensation like you're you're conflating taxes and maximum wages so uh one issue with that uh proposal of just like uh leaving TX Orin to be the null sender during the intervening period and then worry about it later is that um if for the the state

chanels use case uh I was mentioning that would actually leave a a dead zone where we if we didn't have like standards around atomicity for ecdsa transactions kind of in widespread use until we switched um TX origin then in that intervening period there would actually be no way to do the use case in state channels well no there would still be the use oh right I see so like there would still be the current way of doing things but I guess you would not get the benefit of like Metropolis style atomicity Plus TX that origin gas payments although the one thing that I can say though is that you could create like inside of i86 you could create structures where some contract that's

deeper down the call chain pace for the gaster uh directly instead of like compensating the tx. origin uh so for the state channels use we're not trying to compensate for gas um so it it doesn't doesn't work that one but all right see well hold on you're trying to still you're trying to like compensate the guy who's including the uh so right you're trying to solve here is attribution right you want to uh do attribution to whoever

yeah the broadcast transaction one way to get that attribution would be just a data encoded signature of the person who tries to publish that can uh yeah that has an issue that the minor can say oh fool I could make some money and then switches out the transaction but the yeah that's um also just another point is that if you are going to rely on tx. origin for like creating a bribe that goes beyond covering G gas payments then that's a mechanism that's going to be trivially thr rentable by minor because they can just like see what transactions

they're collecting bounties and then replace them on transactions coming from themselves uh that's that's that's uh definitely true in this in this case as well um it like that's definitely uh a feature not a bug of anyone can pay scenarios uh you don't if if the miners are actively trying to front run these it's better for the user because it just means that they're getting in even faster it's even higher level of guarantees there's no disadvantage to the user uh and outside of the the anyone can pay situation or the anyone can publish situation where you're Contracting with someone specific then if somebody else uh who isn't on the list submits it they're not getting anything anyways then there's no front running risk

okay okay but then you can attribution by data signature sorry uh you were cutting out a little bit I didn't didn't quite catch that oh sorry I'm far away from the mic um I said for the attribution of who publishes U the state um you can just use a u signature that you attach to the transaction as data um I I I think that makes sense but I'm not sure I quite understand um like are you talking inside of a new uh contract style transaction or inside of an existing EA

transaction um so if you um the transaction that publishes um the state um there you include whatever the the state Channel state is that you want to send in plus you sign that you are the person your the account who actually does the um publishing right so that takes us back to the atomicity issue which that you can't do two operations from an EA but okay so I think in the interest of time

would this be something we could flush out on the EIP itself um and then also just bring up uh with the with the newer information next meeting sure yeah cool yeah and and I think that yeah this opens up a lot of new things we hadn't really thought about before with transaction origin because I know we've been talking about it for a while and uh fabian's not in here but he uh had also been a proponent for keeping transaction origin so I'm sure he's going to want some uh to participate in some of the feedback in there um so back to the agenda if everyone could just refresh the page um I added and took off some agenda items uh cuz Sophie uh like the

the agenda item from Sophie is gone and I added Martins so um the next item actually are it's a list of three concerns from Martin Hol vend on EIP 208 so uh same EIP we were just talking about um I'm not sure if any of these were touched in the conversation but I'll let Martin take it away yeah so no we haven't touched upon it yet uh basically the thing is that with Metropolis is going to be possible to include the exact same transaction multiple times within a block uh and I'm a bit curious about potential side effects that that that can have side effects on

the clients um and if that's something that we need to to discuss and think about basic can you give an example of a side effect so one side effect is that uh we have RPC interfaces which uh needs to be changed potentially to to return multiple transactions another potential side effect depends on how transactions are stored internally within clients and if there are data structures where which assume that one transaction hash equals exactly one execution and one

receipt um then we it can be internally inconsistent State stuff like that and we have other RPC methods where you send in a transaction hash and you get one thing back we need to modify the perhaps the the parameter set for that so that it takes not only a hash but also a hash a block has and an index so just a quick comment here um unless because of that uh there's some kind of intrinsic gigantic problem this

is not relevant for the hard frog itself because the feature won't be active right what do you mean the feature won't be active we won't activate such transactions at the Hard Fork only later I'm not sure if they won't be active so there will so there is the possibility that a malicious minor will in or we'll just say a minor who is not cooperating with the or running default software will include five copies of the same transaction right so that's I'm

yeah so like we well we can't so like that that is a good argument for why we don't need to care about the interfaces for accessing multiple copies of a transaction to be to be too convenient because like if worse comes to worse the only initial use cases for those will be transactions that are submitted by like basically extremely irregular users and we can tell them to go build their own systems um but it is at the points where like the client does should not break if uh two transactions of the same hash get into the blockchain can we not consider whether there are straightforward changes we can

make to restore the the uh invariant the transaction hashes unique like the the main challenge there is basically that like that would first of all blow the state well so in the current case it would basically create like un unending State blo and I mean we could have transaction deadlines but then that would still have a substantial State BL and that would still require an instate garbage collection mechanism I mean that would depend on on how we did it I mean the simplest way would be just be to reinstate noers as the one required part of a transaction and the rest of the signature verification is up to you um another would be for instance to to have a more

generalized not scheme where where transactions are expected to apply some transformation right I me I'd say in the long term there are legitimate well so there in the long term there are legitimate uses for I mean like first of all making making anti-replay completely liberalized and I would say even just accepting the same hunk of data multiple times so the key one that I'm well or one of the key ones that I'm thinking about for example is like if you have some particular thing that needs to get po and then the transaction that pokes it should just be like a really minimal

thing that has like no signature nothing else and it so and it could just let say poke the ethereum alarm clock and then ethereum alarm clock doesn't stay and I would say that it would be like added complexity for that sort of thing to have to be require nonces and figure out where stances are coming from i' I'd also say that there are there are going to be benefits from eventually moving the protocol to this regime where as long as transactions are correctly formatted they are valid no matter what basically because it lets us do like weird stuff like agreeing on blocks and

agreeing on state rots out of order yeah I mean I agree nonces are are suboptimal even under the current scheme there are times when you want your transactions to be ordered but there are other times when you really don't yeah um but I just I don't know I I worry that um this may be a more useful and a more pervasive and variant than we think or than is immedi obious maybe we can on logs instead of transactions on what story logs so like in general we definitely should be moving toward relying on for things yes um but I I think that um I

mean transactions are still a fundamental uh component of the system so we can yeah um where do we stand on transaction queuing because I remember one of the previous issues was that um with this system you can no longer rely on um two transactions you being executed in the same order because the minor could choose to execute the second one last and then all your code can do is reject it in which case it never gets executed well hold on so if you have H well one thing that you can do right is if you're specifically talking about like regular users then regular users are going to be using a wh listed account and the wh listed account is going to have a non- scheme and so if

miners include one out of order then when you process the block you'll be able to tell that the transaction H an error and so you can just ignore it right but the the issue is that you can't queue up say five transactions because the minor can't choose to well because if it does choose to ex reverse all the the point is that the minor can totally choose to include the second one but then the second one will return an error and so you can just go ahead and return the second one right you can go ahead and include the second one The Miner can just keep including your transactions out of order and charging you for who cares well I do if I'm paying for the gas no but the point the the point that I'm making is that including a transaction out of order is

exactly equivalent to a noop ex except for wasting gas right and so like that it but I'm saying that that's bad because if it's a noop then then you can force me to waste gas arbitrarily so miners can miners can already waste gas arbitrarily they've always had that freedom my guess miners no miners can waste their own gas arbitrarily right so remember that when you when your transaction gets so remember the mechanism that pays for gas is not something that like automatically from your balance right the mechanism that pays for gas for an e86 transaction is itself evm code that's ins that that that has to run so if your

transaction gets included out of order that it gets included and then it it hits an error it reverts which means everything reverts including the Gas payment okay fair enough but then I still I'm still in a position where I can't reliably cue stuff up or if I if I want to I have to remain online and active in order to uh respond I'm I'm still failing to see why the ability to include no op transactions includes like makes any difference whatsoever well so previously I could queue up five transactions and I could be sure that uh e either they will eventually make it into the chain or nothing else to them will but now uh well hold on so you could still so replace the word make it with with the phrase make it into the

chain with the phrase make it into the chain and have an effect yes because that's what you that's what you ultimately care about yeah but if but if okay so put it this way I can I can currently I can broadcast transactions and then go offline and knock here yes and here you'll be able to do the same thing but guys are slightly talking past each other I don't know if you both realize it but one day yeah uh Nick what vitalica is saying is that um that minor including that that no op outof order transaction has no effect on other miners just including it later to get actual gas so it is effect is effectively as if it was not included okay um in that case the other

question is how do we know when to discard transactions from the p po yeah when a so you discard a transaction with nonn when is the a transaction with nonn or non or non higher than n gets included and successfully executes right so then transaction call implementation Le still needs to care about monsers yeah well it still needs to careers right well needs to car in protocol nonces yeah or sorry not in protocol care built like these in nonces that are managed by account code yes which may vary from account to

account so initially at least we won't have any way to we won't have any same way to propagate nonn transactions then yeah might try to execute them in a whole bunch of different orders and kind of give up because they can't find the nonis they're not having yeah so like if you have somec right with in the kind of earliest version if you have some application that relies on things other than nonsense you'll have to like go make a private agreement with until we F out something I mean we could with the revert op code we have different ways to flag errors right so the the non

checking algorithm might signal to the minor uh don't do not yet include this transaction or uh yeah okay this transaction cannot be included anymore in in any future yeah this is something I suggested in the past I think it' be very good if there was some way for a transaction to communicate with limited gas uh what its status is in terms of inclusion like whether it wants to be kept yeah i' uh I'd support making that be a default a part of the default account but do you want to have a gas sender what do you mean a gas sender like some account that the protocol

knows to kind of like check the check their balance to make sure that they have enough gas at a particular gas price they like execute the transaction I mean like that's all part that's all part of the default account code right yeah but you can Dev from the default you know substantially we can you we can do what you can deviate from the default substantially and do some like something no clear you can totally Implement something completely weird but then like miners will not accept it because it's not part it's not part of the white West or like it doesn't match the filter the miners will get to decide the

filter it's not like part of the yes but like if miners decide a filter that's completely crazy then that's their own faults and they and they're the ones that lose money for it like minor B minor B um is the if minor B uses our recommended filter then they should not be negatively affected by minor a using a completely crazy filter so Martin um I think that I'm trying to keep up but I believe that this that this discussion was over agenda item 1.3.1 I guess uh did you want to uh

bring up the other uh points or uh conclude that point potentially no I think we can conclude these three points I just want a bit of discussion about how this affects the clients yeah no I think it's definitely something that's really worth discussing Okay cool so we can bring this back to the EIP um yeah Martin if you could like kind of summarize this in an EIP comment and then uh the others can kind of look there and um uh comment further on it after you know based on the discussions from this call as well yeah sure thank you okay so um the next agenda item is

a.4 um so EIP 2 11 return data copy and return data size uh is that one good to go like I can merge the pr potentially or uh were there any changes I think this is Christians um and looks like yoichi has reviewed it uh does anyone have any comments on that Christian especially on if it's done um I forget did we agree on um if like if you ask for data that goes beyond the return data boundaries did we agree that that's zeros or do we agree that's a throw uh we agreed that um let me look real quick oh a throwing approach rather than filling with zeros I put a comment in the EP that we

decided that on the second of June okay um and that sounds good cool uh Christian and also just I'm sorry just another clarification is that the return data gets uh triggered by um a gets reset by a call call code delegate call or St or static call but not a create correct because creates have no return data I think we decided that it's reset on every time a new stack frame is created okay so on a create it gets reset to null or yes yes uh on create instructions it

gets reseted because create instruction sometimes returns data when it right I see then hold on but like a create instruction though oh I see so right now though the output of like the output of a create doesn't really go anywhere right like it just uh so there's a comment in the AP which says create and create two are considered to return the empty buffer in the success case and the failure data and the failure case okay that sounds good okay great and I'm going to put a note in that uh EIP to clarify that after I

take notes after the meeting uh Christian uh would you consider this done I can merge it and stuff uh I think it can be merged yes sweet okay um if there's no other comments on that uh item 1.5 um so there was a comment on EIP 213 which involves the ZK snark uh verification Primitives uh there was um a comment about oh actually not even a comment basically the thing left to do is to decide on gas cost so I just wanted to bring that up because it's been about you know good 20 25 days that people have been saying we need to decide on gas cost so what is the general um process for deciding on gas

cost or should that just be recommended by a client and then other people comment um um I would so personally I want to wait until we get the uh so I the actually can we just like organize the gas per second values for parody C++ G and python in just one place and uh see what they're like on all four of them I'm especially interested in G because we we I don't think we've seen that yet the question is also do we want to make benchmarks on exactly the same machine for all all implementations we

can uh I think maybe Casey or Martin would know this do we have a testing system set up where we can spin up nodes from different clients to be able to run something like this uh on the same type of machine with the same specs yeah um I mean we we have but I think what what we commonly done is for these measurements I think what has been done is doing it running it on a laptop and I think it would be I mean it obviously makes sense to run it on the same laptop and do some measurements but I don't know what what the standard laptop would be MH

um we do have now um I mean we can run the the evm binaries for parity and get isolated without the rest of the the blockchain stuff and do some measurements on that I don't know if that would be enough or if we want to do it a bit more reproducible uh Ary or uh Robert what um what is the parity team done in regards to this or have yall done gas estimation uh through parody through a process ever yeah I did some Benchmark for EC pairings but not for addition and multiplication I've posted the results earlier I can probably run the same kind

of Benchmark for but check on the same prodware so I don't think we care much about benchmarks for the addition because we I like I personally expect that the gas cost for that op code will be dominated by the gas cost for the for the call op code anyway um but for multiplication and pairings definitely uh can you share the T case you used for bench marking um yeah sure I'll pause them a bit later yeah I think it would be good if if the benchmarking would be coordinated by a single person okay I don't think anyone has

time right now but um who wants to take that up yeah and if no one does we'll draw a name or out of a hat or do something creative Martin uh couldn't you add the block test to Hive that basically just a full block that simply does these uh up codes and then just run it against different clients yeah uh I'm not sure how how stable that platform is with regards to know okay so in doctor stuff like that okay

just saying that Hive does have support for some form of benchmarking so maybe work but maybe not yeah I mean hi can probably do it but I'm not sure if the I don't know how how how the Asia systems are on they same stuff every every time around where it oh I didn't mean to run it on eia I meant just locally yeah we don't actually need the same person or machine to Benchmark everything do we we can just Benchmark against a known Baseline like ecdsa signature uh [Music]

validation so Hardware has nothing to do with it Nick like that won't affect stuff well if we determine that it's like twice as fast as our slowest operation then we should price it at you know on average across the implementations or worst case across implementations then we should price it as uh you know half at worst operation but there might be variations in the in the Baseline itself across the implementation so I'm sure right but the implementations already have to be fast enough to keep up with the blockchain and we we presumably facted that in when we pric the gas um for the existing operations yeah I think we can we can organize for all implementations to offer an isolated uh vir machine binary

to run don't we yeah I think I think that's doable um uh organizing it I I should say um so on the getter chat let's talk about doing that um brainstorm a little bit more um but yeah it sounds like that would need to be done for actually any of the op code related e changes am I am I correct or there some that are just kind of a given or like we know already so most of the others are just variations of existing op code so nothing has to be determined there okay so yeah let's either do a thing

anyone else have comments um there was a discussion about benchmarking then new OP course um I I w't say that we could um easily add more test for that in the blockchain test form they could make a transaction that would call single or code so many times that gas blog gas limit is lows like Al said 250 million gas limit is okay and so we could spend all of that gas to call so many times in specific op code and see how it consumes the resources on every client through

hi okay um Dimitri would you be okay um leading that or at minimum getting kind of a chat together or organized or using the allord dev chat to um uh to to get support from the other clients and get that together it sounds like this actually could fall into the to the testing wheelhouse this test would be able to walk on high so you don't need any specific support from other clients you could use five okay cool yeah regarding that though I'm not because hi then you will have also the the added the the

time if you mean that such a stress test might Crush something on hive then clients require to implement General state test or blockchain test at least [Music] and then they could run this blockchain test through the testing tool or they could just see the script in hi and somehow implement it locally and run block input process on their own environment so per both approaches because I think one could be to do it in Hive and another approach could be to run it as R evm code just against the EV and binary and then we can see if the two

measurements match each other each other um I think um we could um add this issue to our documentation process so to help us developers run benchmarking tests on their own environment with their own yeah that's a that's a good point uh there actually I sent out a call on Reddit a few weeks ago to get people to help with Metropolis testing and we had literally over 85 or 90 uh individual emails from people asking to help test uh and I've also been getting some known community members who are wanting to help test so we've written up

some preliminary rough documentation and uh have a lot more resources written up on lll and some of the stack uh and like evm and assembly requirements to be able to do that so we're going to release that today um I'm emailing all 95 people back and then or 85 people back and then posting to Reddit again so maybe uh we can set up like a spreadsheet for people who are testing on their own consumer Hardware to put in what they're doing I a lot of people probably wouldn't have the knowledge and time to do that but in combination with you know us doing it ourselves I think that'd be a good Benchmark so yeah okay so it sounds like

uh we'll talk more about this in the allore dev channel uh was there any other comments on that all right cool uh so item number six uh is going to be uh EIP uh 214 static call um vitalic made a comment on various potential errors within that um in the static call uh EIP so you can go ahead vitalic yeah um like neither of these seem very controversial but basically there's like the s store bytes op code referenced in there and that op code was one that I proposed about a year ago but I've since withdrawn that proposal and it doesn't

ex and that outut doesn't exist so so that shouldn't be in there and also there's a sentence that says they only they also include call and delegate call with a non-zero value but there's no such thing as the delegate call with a nonzero value because delegate call doesn't have a value as an argument so those two just like purely stylistic elements uh and then a third one is that says something about the the value it's it says its value is always copy to sub calls or subc creates and they are what's like there's no such thing as a subc create of a static call because a create inside a static call always fails so like no substantive changes but just like three things there in there that should be changed in the text because

they're uh they refer to things that could that are not possible okay I think the the second item wait a second so sorry so the the the first delegate call is meant to be a call code I guess so also include call and call code with a non-zero value that sound better um hold on but then the next sentence says as an exception call code is not considered State changing even with a nonzero value okay I'll take a look at the full context and modify the quy cool so does that finish uh up that

item vitalic yeah okay great um so uh Item B updates to testing uh I just kind of explained some of the documentation and other updates from uh some of the stuff I've written up uh Dimitri and yoichi and um like Martin anybody else who's doing testing do do you want to kind of give your update on where we're at with that and some of the uh improvements this is Yi uh I joined this testing effort like a month ago and I'm new to the whole process so I made many issues so I adding I'm trying to add documentation to this test T command

that produces test cases from sources uh this documentation is in a date stage of and I'm also changing test test so that it causes errors when people make sping mistakes in the command because I wasted lots of time um not noticing I made a spelling mistake and so on so I'm kind of doing a Ginia pig to this process and trying to fix problems okay and from my part we created a Docker image of the test test so new contributors for test would just

use the docker image and not bother with building from the so building be client and solc compiler for test generation and then yeah we're making a documentation how to use the test and manide the docker container does does anyone of you guys you have any kind of estimate about how much test coverage the tropus test coverage we have at the moment I could try do that I guess 35% all right good all right um and I

just posted in the Hangouts chat and I'm also posting in the getter chat um the documentation summary so anybody who's interested in helping test um uh or if you know anybody who'd be interested in kind of getting more familiar with the uh internals of ethereum and what we're doing with Metro um go ahead and pass them this I'm going to also post this to Reddit uh right after we get done with this call so let's see where's the agenda cool uh anybody else have updates to testing okay great so uh the details and

implementations of the eips um let's do updates from the client team uh on the agenda I put links to the poll request that uh kind of compiled uh or tracked what eips are being implemented per client uh so we can start with gu uh Peter do you have a dates or anybody else from the GU team sure so we had a discussion yesterday about it and uh with Jeff he said that um most of the eips are done if you open the pr you I just updated the list the description so that there's a whole rundown uh in theory all the up codes or most most of the IPS I done one of the EIP that Jeff missed that I'm going to

try to add on Monday the IP 96 the block hash stuff so that one is not done and uh Jeff is still um Miss uh tweaking the thep 86 with uh regarding the create to op code apart from this um I think Felix is uh Felix wants to revamp our internal test so that we can properly test the Metropolis changes on our CIS and U let's see where where that leads us so in theory it's mostly done just the final tweaks are going in in practice we'll see the test all right excellent um that's great uh parody uh Ary or

Robert well yeah we've completed our implementation a while ago and did some smaller changes for whatever was discussed in past weeks and yeah we're also waiting on the test mostly uh also for uh mod XP there's new Gap cost calculations but it seems in the discussion that maybe there will be even more updates to that so we haven't quite uh got that ready yet okay great that'll be useful when we're doing the comparisons um across clients so that that's that's good news okay great um CPP ethereum um I think I have yeah there's a PR that kind

of lists some of the progress so um is uh pavle here or Christian you can speak on it I think Andre knows knows more about it oh yeah Andre yeah um during last two weeks we merged the block has implementation uh and also looked to C promiles and also made a couple of minor fixes like uh uh throw on return uh data copy accessing out of bounds and check in the modex guess cost so what's left is uh create two up code support is also is almost ready I

think yeah that's it okay great um cool update um so on the yellow paper uh yoichi uh it's finished but now the focus is more on how to get to the pr so okay great uh and then uh py theum or pth app uh I saw Jan was in here but I think he had to drop off so vitalic do do you are you with the update um let me see and while bal's looking that up are

there other clients in this chat that I missed on the list I think I got everybody who regularly attends meetings and then also while he's looking that up um is it does anyone have an update on ethereum J and Roman's team uh they haven't been at a meeting in a while and I believe that pretty much all of their uh projects are stacked right now does anyone had contact with Roman or his team in the last uh two to four weeks I am getting the feeling that they

might not have enough resources to uh do all all of this stuff especially since their a lot of their projects haven't gone far yeah I I mean there was a post from gav uh that said that Roman was taking a break uh but didn't give much details besides that and they've been dead silent on their slack for about a month so um I'll I might try to reach out but otherwise I think we should consider Java ethereum client not to be up to date um along with Ruby and a few others cool so yeah vitalic whenever you find that um uh update or if you want to just post it later in the comments

that's fine too on which update was this again uh how far P ethereum is or I oh right right um I was trying to look this up but I the prob is that there is into like one nice set commit that I can point to so so what I mean what we do have is that I and I could just list stuff that I know is implemented which is um all of the pre compiles static call um revert um I believe return uh uh return data though possibly not with the change that makes it um out of balance stuff uh return there then EIP 86

definitely um 96 not yet 90 998 not yet like all of the ones that don't have to do with transactions I'm waiting until we have until we have block like blockchain tests for them and revert off code yes and all the other stuff yes okay great um and are you primary on that or is it Jan or who's who's kind of doing the python I've been I've been primary on eips okay great just so I'm aware perfect um so the next thing on the list because there were no other clients in the chat uh Review Time estimates for testing and release the last time estimate we had

was between um August and September for testing and release period uh is that does anyone have a comment on that if it should be changed um in any way okay great yeah sounds like from the testing um update that we have and the potential that we might get an influx of testers who can accelerate that um we might know more next meeting uh so any other comments on that um yeah I'm excited to see

these contribut um I'm I think some uncertainty is how it goes um maybe the overhead of answering questions and so on we overway in the first one or two weeks but after that I guess we can get it to the state where this additional people make the process faster yeah I agree and and I think that we can kind of guide some of the people to uh also update some of the testing documentation as they're going along to not have to go through the whole geter Channel every time someone has a

question um so yeah that'll that'll help that a lot um I think that was the last official agenda item does anyone have any other things they want to bring up um can be non- agenda or whatever okay well the skipped first genda item I remembered what it was oh that's right okay great yoi yes so the if one sentence is missing from the if and I will work with Alex B um to fix that um the missing sentence would say the the instruction returns data which could be available in the same way as return the data

returned from the return instruction or something like that that that one sentence is missing from the specification section of this e um I can work with Alex B to solve this okay great perfect um so uh okay cool that I think that covers everything after that's changed we can look it over but yeah it didn't look like a big change like you mentioned um cool any other topic or items or anything i' um i' kind of like to be caught up on you know any conversations that anyone's had about e56 cool uh which one was that

again uh let me look the stuck the stuck funds one that's right yeah so um that was brought up by who was it so um I'm having to find it real quick but basically I talked to some exchanges fairly recently there was a group uh on Skype who got together um it was actually more than exchanges it was exchanges and then other interested parties in the EP and they basically asked me so if we wanted to get this done how do we get it done and I gave him the whole process which was you know get Community Support do a an issue on the Eeps then a formal EP and then uh kind of see which developers are interested in implementing Etc uh and and I think that the conclusion they

came to at this point what I feel like and they they can kind of answer for themselves in the EP was that um they uh they don't want to put in an Eep for that right now because uh it would be controversial and it would kind of seem like a whole another thing especially coming to Metropolis the other thing is at the point where we've pretty much locked down the um EIP it would be uh too much time to test and also to figure out a democr or not even Democratic just a a process for determining which stuck funds get out um vitalic I know you wrote the EIP do you

have an updated summary of your thoughts on the EIP uh with the recent quadriga um CX hack and stuff like that or not hack the other thing they did right so basically the challenge is that with uh with quadriga is basically that uh a e 156 works well when you have an entire class of situations where like you can very clearly identify that first of all you have an you have an account where money is not accessible and second where you can identify who like a party that that money should reasonably belong to right

so like one very natural cases if money goes into an empty contract then you can have probably send sending the money to a Creator is like not that bad a thing to do um the the challenge with the quadria case is basically that the money is stuck inside of a splitter contract and the splitter like with the splitter contract it's much harder to Veer like you you can we can mathematically reason and show that that money is stuck because like any transaction coming in we'll have the same coming out but it's so like much harder to turn that into a kind of principled rule that would make sense to stick into into the protocol and it would um the and the other thing

is obviously identifying like basically whom to refunds like where that money came from inside of the state so that we know wh whom to refunds to so like in general I would really rather avoid making contorted rules that only apply to one specific case because I feel like those kinds of like those kinds of things uh and in general like said bad precedence and should be hand and uh should be done only only in the most extreme situations and whereas something where like you could if you can um come up with some some specific class of users where like here's people where like a

case where like a few thousand people lost uh lost money and it was all done in the same way and we have this kind of very clear and kind of unambiguous way of determining who a reasonable owner is then it makes quite a bit more doing something like e156 to recover the funds is quite a bit more reasonable and that would be the case of something like the implementation error in ethereum JS util that um caused some lost funds is that could that be entirely like technically proven that were lost because of that ER okay so yeah so that's you might notice in specification version two I have a a function to clear lowercase hex address

and like it does that okay and it sounds like the people who are the most vocal about this and I mean it's not a huge amount of people but the ones who are the most vocal do not fall in that category of something that can be easily checked like you have V2 so there are like basically three at least I know of a few major categories of losses right so one of them is some empty contracts where either like some like one case I could imagine is a guy sends or someone sends money to an account or well we'll just say ether to an account and uh that they think that that account has code in it

but actually it doesn't and a contract creation failed and now they have like no way of getting that getting The Ether back so that's something that we could that we could fairly easily get recover and um in other cases where people send ether to an address on the eth Chain where that has that only has a contract on the ETC chain so that's also recoverable in the same way then the JavaScript bug is also easily recoverable that's the second case the third case is um people accidentally sending money either to junk addresses or to addresses where they accident like either either the zero address or addresses where they accidentally led off and missed a couple of characters at

the end so the zero address is kind of hard to recover from but if if it's a few characters at the end then that's easy to recover from because you could basically just declare an address which is some some low power of 16 multiplied by an exist um an existing address and then there's like weird very special cases and like quadria the quadria thing unfortunately it's like close more like a weird special case I see okay Vlad what were your thoughts on that or was that the update you wanted yeah I mean that sounds that sounds pretty reasonable I mean I totally get it um

yeah cool okay uh anybody else have any other um off topic or non- aggenda items to bring up so I still have something um please me if that was already discussed last week uh but so am I correct in that uh after Metropolis will change the way addresses are uh calculated yes they do um yeah and is the community appropriately aware of that I mean there are some techniques where you where you send ether to sim address and then have a transaction that is not yet published which will later

create a contract dat address and these these things will fail after right right yeah so the community should definitely be made very aware of that um and so I mean one nice thing is that if we do commit to 156 then like anyone who isn't or to at least the first part of 156 then people who aren to wear will basically just like automatically fall into that first class where they send ether to an empty contract um if we end up deciding that it's too risky then we could always like do some uh weird some weird bti flipping thing where we uh so like one example would be that we that of a way of making this

change totally safe is we make it apply only to EIP 86 transactions so actually no that would be weird because yeah no that's yeah that's fine yes so we make it only so if we cared about making this change like completely safe no risk then we'd make it only apply to transactions where the sender is the n cender and then we also have to I mean it also applies the create up code right um right no no no it doesn't apply to the create op code remember that's why we created the create 2 op code uh oh yeah right right no Okay so the concern is the

community not realizing the breaking change or I would it be would it be considered a breaking change from the point of view of most app developers um no so like the main risk that I see is that um like well actually I mean I don't think there are many users that rely on creating contracts and or create sending to addresses that are not going to exist for a year the main like if you told me that guy X um you know or someone lost money because of this then I would bet

that there's like more than 80% chance that it's because of this in combination with another bug that that they had so like an example would be let's say someone send um accidentally sends ether to a contract and or to an account and that account is exists on the ETC chain but not on the eth chain and then if we had not done this then they would have the ability to recover by making the exact same contract on the E chain but because we did it the aura scheme would have changed and they don't have that ability anymore so like there are going to be cases where a uh like this change would increase the risk of someone

losing money in combination with them making making another kind of mistake but like those are mistakes that have a sub a large probability of causing them to lose money in regardless of what we do yeah I think it's something to do just before Metropolis if you are planning to create contracts that certain addresses maybe after Metropolis you cannot do that so yeah before the metrop police hits you yeah so basically like I see two routes here right one of them is like slightly slightly higher risk which is that we are just like be loud right now about the fact that this is H that this

change is happening and the slightly lower risk thing is we basically just make the change only apply to EIP 86 transactions and like honestly I'd even I'd be uh I totally cool with making it making the uh making an only apply e86 transactions so like basically only make only making the uh the the change to the way the contract ad just is created if the sender is the n sender um but like I'm fine both ways okay hey vitalic could you do a summary of that and a quick comment on

the EIP uh to kind of bring up the possibility that that can happen and I think that that can be easily decided on the EP um and then uh on the on 156 and then I'll go back to Christian we're we're I don't think that can go in during Metropolis I think it was determined last meeting that that it's basically we don't have the time and the the testing and all that other stuff but if it were to go in in the future would it be a higher level of difficulty to do specification one or two of EIP 156 uh in future hard Fork so would it be the same level um you mean like is it harder to do it in serenity versus do we get in Metropolis correct I expect not okay I was thinking

the same thing the I mean for specification uh for for the ones like um that are more special cases that we would have to come up with a system for and we're kind of leaning toward not doing in the first place that would be harder over time just because of the community growing and getting consensus over things but yeah for the other two because they're technical I think this can be brought up in later meetings for hard Forks MH uh Christian uh did your comment get fully answered yes okay so I mean perhaps we should also just directly reach out to the community and ask whether someone is using that and that they are question ask whether they are aware of that change and from from the response coach

whether we uh yeah how we how we specify uh the creation okay great I can uh in the next week send out kind of a post across all social media channels and getter channels um anything I'm kind of in but beyond that I think that's pretty much all we can do and so I might even Stick it to Reddit if the other mods agree all right cool um I think we're wrapping up uh everybody change your passwords and uh make sure that you have tofa enabled that is not SMS that's on Google Authenticator because we had uh two mods uh of Reddit this morning uh their passwords were compromised and someone uh either was sending fake

messages or went on and I think they changed like some stuff on Reddit so uh go ahead and change everything um and uh or all your passwords I should say cycle through them cool all right I think we're good here uh thanks everybody and we'll see you in two weeks you see you bye byebye bye bye see [Music] you

[Music] [Music]