All Core Devs - Execution #36
All Core Devs - Execution · 6 Apr 2018 · 1:31:11
Hudson Jameson leads All Core Developers call number 36, where Ethereum client teams discuss testing, standards and research. Remco Bloemen updates EIP-712, now narrowed to safely hashing structured data for signing, and Nick Johnson says it is moving in a good direction. A proposed precompile for Ed25519 signature verification draws doubts, and the group asks for more use cases. Piper Merriam facilitates a debate on tweaking the Ethash mining algorithm to break new ASIC miners, and the developers lean toward no fork for now. The call also covers Vitalik's April Fool's EIP to cap ether supply near 120 million, which people took seriously, Danny Ryan's Casper progress, Nick Johnson's EIP website and bot, and client updates.
Speakers
- Nick Johnson
- Hudson Jameson
- Danny Ryan
- Martin Holst Swende
- Piper Merriam
- Daniel Nagy
- Remco Bloemen
- Dimitry Khokhlov
Topics
From All Core Devs - Execution, hosted by Ethereum Foundation.
Transcript
[Music] [Music] [Music] [Music]
[Music] [Music] [Applause] [Music] [Music]
[Music] [Music]
[Music] [Music] [Music] [Music]
you okay hi everybody we're gonna go ahead and get started just a reminder if you could mute whenever you're not talking that's gonna help a lot with the audio quality and if suddenly I go offline it's because of my cat who just walked across my keyboard and hitting the Escape key but I think I'm safe okay I'm good anyways we can get started with the agenda it's pretty packed today the first one is gonna be testing so let's go ahead and get an update from Demetri on that and anyone else after him who wants to update on that yeah hello guys I have the first results of the test
execution via RPC on my local branch of CBC on client I managed to execute all of the state tests within the seven minutes so this is a research update and now I'm going through the painfully slow process of integrating all of my changes from my testing branch into CDP client so we're discussing with a CBP team how to optimize those changes and then what should be the air PC meters so the current state of our peace meters that I used as a steal on the same link and richest repository it's not final so everyone welcome to discuss those and
then if someone could provide me a client which managed to execute those tests faster than seven minutes it would be a great great yeah so you need a client that actually runs the news type of tester saying yeah the issues that test air PC me to them me there's no consensus about those made of some still struggling with that one method of how to add a new account or is a transaction with secret case so the discussion with virtue was was
it should be a new testing method for executing a transaction is a secret key via RPC or registering a new account who is the private key which then could be used to sign those transactions so maybe you could help me with this I mean right now I wonder what was your opinion so the question sounds like this which one is better and your PC me to register a new account with private key or a new methods which provides transaction and the private key
to sign it what's wrong with syndra transaction how come the signing can't happen offline central transaction requires this account to be registered in this in a key store no it doesn't say no transactions in a pre signed raw transaction that doesn't resign so the transaction should be already sign Union yeah that's what I'm asking if it like you're saying why if I understand correctly you're asking for a RPC method standardized to import an account by sending in a private key but what's wrong with signing the transaction and sending it in over sin draw trade no in
this option and the tool which owns tests and you'll have to implement math needed to sign the transaction and well I think signing should be done on the client side are we talk testing yeah okay I'm not sure I understand that logic but maybe we can talk about this offline yeah okay yeah Dimitri if you could summarize what you just talked about and put it in the all core devs Channel I think then we can respond better on there maybe some of the clients aren't prepared for an answer okay I lost the link to the discussion on my github issue yep thank
you so much and definitely I posted in all four devs and we'll talk about it next meeting as well and were there any other updates from anybody else about testing okay the next agenda topic is e I P 712 add s sign type data as a standard for machine verifiable and human readable type data signing with etherium keys so we talked about this last meeting and there was a lot of support for this however there was also some some talk about making sure that everybody in the ecosystem was on board because it was the decision was made to
not keep backwards compatibility today we have Remco on the call room Co if you want to have just a quick introduction and how you're related to this e IP so that you can better champion it yes sure hi so I took over the ownership of ERP 712 from Vallejo and who originally proposed it and and since I've moved it a little bit originally it was a way to communicate kind of the interpretation of the data to be signed to the user agent such that the user would be presented with a more elaborate view and understanding of what is to be signed as
I was working on this problem I realized that it quickly splits up in a number of sub problems that need to be addressed when it comes to signing arbitrary messages I'm true user agents and and quickly in order these these would be hashing of arbitrary messages without collisions any security issues of course domain separation when messages do naturally collide but you still want to somehow make the signatures incompatible nonce s which is something that I don't think has been addressed in the discussion at all and with that I mean how do you prevent replay attacks so standard
aetherium transactions use nonces for that the sign messages do not have that currently we require every implementation to come up with their own solution to this which might end up being the only viable solution but it might also be something we can address in some standard way to prevent people from shooting themselves in the foot this way and of course the original issue of how do we present all of this in a user-friendly way such that people who are relatively novice to cryptographic signing schemes can still use them securely and relatively trusted now this is a lot for one standard and I mostly narrowed this standard down to
the scope of just defining a hashing mechanism that is able to hash messages into a bytes 32 in a safe way such that developers can basically just hash any Strutt they want and know that they're safe it also touches on the issue of domain separation um yeah and that's basically where my wary IP 712 is is is at the moment ok so it sounds like you're still getting feedback on the EIP in addition have you received other at least since the last Court have called two weeks ago have you seen other people
or other groups coming on board with this and saying that they support this maybe any hardware wallets or things like that I noted the original IP 712 got some early uptake maybe a little bit premature from meta mask among others I think right now they are waiting for things to converge before they want to reinvest in implementing everything and I know that Nick Johnson is quite active in the comment section yeah Nick what's your take on this right
now unless it's just basically editing the EIP for technical properness so I was pre skeptical of the original standard sign tap data with the original idea being you know to enable UI display of this but I recently reread the the revised EAP and I think it's moving in a good direction I think it could be really useful standard I just did a review in the bunch of technical comments but in general I think it's really promising thank you yeah I'm sorry I read through the 20 comments in indeed I noticed some of these issues
and I will definitely address them I hope you are generally on board with the direction I'm taking it I know it's more complex than than something like ABI encode and yeah I explained why I was let in that direction yeah no I'm having reread the updated standard on I'm now on board with you I see where you're going with it thank you so if I may eirick question I have not died into the revised version but I'm curious about is this standard generalized enough to be kind of a top-level standard or should there be
some other form of top-level standard something like e1 91 and have this as a subgroup of that or is this does this accommodate old use cases I I made it really really generic and right now it supports things that are not even supported in solidity at the moment so it should be extremely future-proof in a way one of my suggestions and the recent review is to make it a subtype of 191 and then we can cover of a you know other data formats as well I think that's a good idea I realized that right now the only differentiator between this
standard and any other signing message that we might want to add or hashing yeah encoding that we might want to add in the future it's just a 1 by today 0 X 19 I think that I turned into a 0 X 1 we can we can have larger differentiators it should not really matter okay great so just so in a way this is already then let's say compliance to eat 191 right if you have a version number it needs a slight tweak it to be 191 compatible we
should take this offline on the PR discussion though No cool so it sounds like there is a lot of support for this I think it does need to be polished up a little bit in my opinion just because there's still some few more discussion topics happening and then if we can as much as possible get a feel for which developer tools companies and hardware wallets and other people who rely on this get on board if we can get as much of them as possible I think this can be something that is accepted in my opinion obviously the other IP editors will have to chime in and stuff but that seems like it has good momentum right now ok can I ask one final question before you move on to the next subject so right now
the scope is limited to a hashing arbitrary messages and it touches a little bit on domain separation but I don't think it fully addresses the problem of so domain separation yet that's an ongoing discussion it does not touch on the issue of non search and preventing replay attacks is this something that should be covered is this something that we want to postpone to and a future AIP um it sounds like you would want to put that in as early as possible I mean if they can if it can cleanly go into the current EIP that'd be my opinion I haven't read it though so I don't I
don't want to give an opinion without reading well it it's it's a separate issue but it is one that might affect how any signing standards at this particular lower level is implemented anybody have a comment otherwise we can take the comments to the IPS and you can we can ask on there yeah okay cool in that case thank you so much Renko for kind of giving us that overview and giving us an update on it and I hope this goes forward thank you so the next agenda topic is a IP 665 at a pre
compiled contract for the IDI two five five one nine signature verification that is by Tobias Augustine who joins us here today or our Burstein sorry who joins us and he's gonna kind of explain just his just real quick what the summary and motivation is behind the CIP and we can try to get a feel of if anyone can use this for any other use cases could you speak up or get close to the microphone please because yeah so the the desktop client didn't work for
me and I could hear you great and go ahead I wanted to propose adding a pre compile for this specific major procedure that is quite popular curve I'm quite another developer Ben 10 Ben Stein and a lot of projects and a lot of protocols are using actually so for example SSH there's the possibility usage in keys using that cryptic curve and or TMS paste or illness servers and so the motivation is to bind actually aetherium keys or if he
addresses two two three five one nine public keys or to verify signatures signed by those keys and to actually bind both identities or an identity on etherium to identity on a external system so and obviously it would be possible to program that in usual or in IBM ID code but it's too slow too too costly and gas so the proposal is to add a pre compiled for that signature
verification and yeah well I think it's easy user further so we could use it I'm working for a project crossfire oh we we using those keys and we would like to bind those to etherium identities or addresses okay sounds good does anyone have comments on that anybody who's
looked it over like browsed it Oh Vitalik and friends I think I can hear you typing if you could mute I only have a comment in I can add a couple of anecdotes of companies that have requested this feature from paradiso some just say that there be and precompile is too slow and that Edie would maybe be faster and like they're trying to do some unchain crypto stuff and like either they want the IDI curve
specifically or they're just like trying to find a way to do it in as cheap away as possible and so the B and pre-compiled is not hold on so I mean that'd be B and once when he alteon once when he aid is not by itself like as a curve much slower to execute than that look there's nothing inherently mathematical about the curve that makes it slower to execute insecty right like as I understand is the only reason why the implementation implementations have been slower than sexy so far is just because there seems to be better and more optimized libraries for sex P than there are fall beyond 128 I mean so
probably true but like they go implementation recently used the B and implementation from CloudFlare which is now really fast on 64-bit platforms but pretty slow on anything else on parody you were like in the in the middle on all the platforms because we're not using assembly right so I guess one question is like how much do we need to care about 32-bit platforms given that a lot of machines most machines are perceived probably 64-bit already and the ones like we've already made a decision to kind of not care that much about older hardware because of how difficult it is to run I
mean if you're a I'm on an HDD you or even on anything with a low amount of memory so like my instinct would be to just favor making more optimized at like or finding or potentially even like supporting and subsidizing more optimized implementations for the existing BN stuff like if at all possible right because that's just something that doesn't really require to dissensus work yeah I think that's fair enough I I don't know of any specific use case that requires the needy stuff so I know that the easy stuff does have like real
practical advantages because like it is slightly more efficient to a newer FOIA has batch verification and it has like good cryptographic properties because the most the signing process like doesn't have like a branch can do like branch conditions that make it easily vulnerable to side channels and so forth but like I guess are those benefits large enough to be worth an entire new pre-compiled I mean plot I mean I'm inclined to say like we not like won't be up with them at the end like have like for that curve that was enough because they're like it created an entire new capability of doing peering based cryptography but here the games
just seem more marginal okay do we have any other comments on that my comment would be in the past we sorry about that cough in the past we've talked about and no longer putting in pre compiles because II was coming up and I'm not sure if we're still of that opinion or not just because the time it would take to implement and test the new pre compiles would take away from the time implementing stuff like Casper sharding and he was him and the fact that he was and can sometimes run those curbs natively is kind of what I remember people talking about is that accurate or can anyone correct me if it's not yeah
so I've definitely liked my understanding is definitely that you was was fast enough to just implement all the cryptography and he was um I mean I would be will I personally would be willing to consider pre compilers but for cryptographic operations but only if they really bring substantial added value and at best points you know we have hashes we have signature algorithms we have hearings we have beginner arithmetic them I would say at this point like if we wants to like expend units of work on pre compiles then my preference would be to focus on both making like making all TN once when he aged more efficient and just really
cutting down the gas cost to make it viable and seeing if we can cut down the gas cost of big uns rithmetic as well because like I yeah I talked with his equine people about a week ago when they were complaining about the yeah - costs for a sequin verifications being like crazy high okay I see so yeah Tobias did you have other comments on that what it kind of sounds like is what we would need wider support for this to go in to base if you're talking you're very
muted I would be verify or how would you find ad curve um at this point you wouldn't I guess would probably be the answer unless someone has a better answer I'm just just to interject for my part edie 235 1 9 would be quite useful for DNA 6 Indian ace just as another use case hmm is it possible to somehow quantify that and like how much my use would it
like enables think yeah I'm more dinner service or I've just grabbed the root zone for DNS and I'm doing some gripping over it now to give you some figures but it'll take a few minutes ok so I think this is something we need to explore a little bit more to see the usefulness so do we want to just come back to this topic later in the call yeah on the side note victaulic mentioned low in gas cost for arithmetic operations and pre compiles and I think that I think that's a good idea I some measurements show that I mean the basic operations can probably be cheaper than they are already with some
dedicated libraries and optimizations base for the go client and I think we all know that it's basically the disk accesses that take the lot most of the time and needs to have a heavy gas cost they are if Maddox could probably be a bit cheaper so that's something we should benchmark a bit more discuss if we should change the gas costs again okay sounds good tonight someone have a comment I can just say that I I can try to reach out to the people that asked for the IDI to 5x1 line curve and ask
them to put in their specific use case on the IP mmm then it can be there for consideration that's a really good idea Tobias does it sound alright if we just start to kind of collect more use cases and add them to the EIP yeah that sounds perfect great thank you all right thank you very much all right getting on to the next agenda topic we have modified block mining to be a sick resistant that's something that Piper initially started and has now grown into a large topic of discussion in the community so Piper if you can just give a quick background on how that AIP started and where it is now yeah I can do that um so just as a disclaimer upfront um I
decided to just sort of facilitate this discussion this is not an area where I have the expertise to be making decisions so I am acting more as a facilitator we've got an EP that was merged as a draft a few days ago that proposes some very low touch changes to the Etha hash algorithm things that I if I understand correctly should be very easy for clients to modify their you know internal block ceiling to
accommodate these without any you know really significant changes the idea behind this is not to improve a sick resistance as much as to an attempt to break existing hardware and at least from my perspective that approach is intended to be a short-term fix to push the you know assuming you agree that Asics are a problem or that we don't want them on the network the hope is to push them out far enough that we have time to get proof of stake into place that also works under the assumption that proof of stake is still far enough out that Asics coming onto
the network and being on the network now will be a problem I was yeah so anyways that's the high level description of the EEP that's currently in process or under way I know that there is a very easy path for us to take which is do nothing and I am I'm not convinced either way that that that we should do something to break them or that that we should sit back and just keep focusing on the things that will permanently fix this and part of that is just not knowing very clearly what the timeline is likely
to be on proof of stake being sufficiently far enough along to actually fix this so mostly I'm hoping for people with more expertise and more knowledge to chime in to the discussion so that we can actually come to some form of consensus on this so I'll probably repeat the comments that I made at the getter which is that like first of all I mean well there is one thing that I am so first of all sorry of italic I want to throw one more thing in I have had one piece of back-channel communication that indicates that we can expect these to not be programmable the
the current Asics that are in production there's no way to verify that information and so you know you can you can take that as you will but I just wanted to toss that one more thing in there yeah so look what I said in the dinner is basically that like first of all at least if you look at the III the one that got released a couple of days ago the efficiency gains are relatively small compared to existing GPUs so for my for my Chinese sources I currently a 22-inch at a 20 mega hash minder cost about $2,500 but the thing that that bit mean is offering is 180 mega hashes for 800 dollars which is only a 2.5 x factor
improvement and that basically doesn't like that plus the fact that I know that when we were building each hash we did an analysis and we basically showed that the algorithm actually does succeed at being an i/o bound rather than compute balance which basically means that even if you may replace the computing with you know like super fancy people said it wasn't magic it would still but you would still the the speed increase would still be limited because it would have to like the bottleneck would be ramp well at least up to some points right like if the computing launched it was extremely fast and it could all Democrat just like pseudo like verification process but it all fakes there even close to doing that so those things together basically implies the the AO is
that it seems likely that the ASIC is just like a regular computer was a was a better piece of ram was up with uh anything non-essential like that's in the GPU or that's in the RAM stripped out and like the other thing yes that I heard I mean something about like basically these like Asics using some new kind of Ram like either gd-r gd-r 3 or and like something that's otherwise fairly hard to get so that would imply that you know like it is just basically a better like a computer that's optimized to word I'm IO hard group of upper fork algorithms in which case the
immediate concern is basically that like there is nothing that we can do you know and because like even if we just replace some if hash entirely with like equi hash or whatever that you know what the hell Munira use this or something similar than it would like basically the ASIC would still just be able to do it and it may be the case that that's not true but we just have no idea you know at least right now what yeah what specific protocol change actually would manage to make a difference and like given that like the only thing that I think would reliably stop these particular Asics is
switching the proof of works is something that's just not even IL balanced at all so one example that I've heard up is just switching it to shots Reid but like with the chain I will they changed that drastic idea inclines not to do it because like first of all if we switch to something like that and that's the last asic resistance which would mean that we explore it again in something like six to twelve months so we're only buying a bit of time and also the actual development effort of making good GPU miners for sha-3 and just getting everyone upgrade is likely to be fairly chaotic and really anti detract from work for more important things so at this point I get in it I personally do mean quite significantly to word no
action I mean the other the other reason to lean to where no action is that if you just don't get a worst-case scenario look worse case scenario was basically that like you know bit main controls like a very large portion of the etherium network for some period of time and like the day they and they can end up trying like you know look this is not Bitcoin right like miners are not in control here if there comes a day when they have been a majority hash power and they try to use it for evil then you know the net basically will just speed up like Casper's development and you know like to hell with any remaining bugs and just
one and try really hard to launch the thing within a week and mining reward so it's down by 90% so that's um like I just don't really see a kind of game for them that doesn't consist of just like acting in ways where they can make sure that it doesn't that like only plausibly reveals that they have something like 20 to 25% of a cerium hash Bauer do you I feel like I've asked this question before and I'm but what do you
feel like the timeline would be for us to be able to get a version of Casper in place that would Danny miss in progress of like finalizing the code for X the second stage of the test net and it's once the the one of our goals for the second stage of the test that is an algorithm freeze and like full specification of the algorithm so that's something that you know is totally ready for gas and parity to theoretically start implementing now it is in progress of also being formally verified and also being checked by yet multiple groups of academics but if we really wants to like
like if 51% attack concerns do me I demand it then we can just totally skip all of the auditing and verification stages right so yeah like basically if gift and parody start implicit higher priority to implementing Casper FFG then even that by itself gives us a bit of insurance okay and formal verification of that is something like six months out or at least the timeline for that is six months little run time verification Gramps I think they have like five and a half months budgeted I don't know four and a half months but budgeted and they started halfway through March and
they're making like really solid progress daily and working really closely with yuuichi and they actually well yeah I'm gonna can I go ahead and just give an update on what's going on with Casper because you're touching on that and I wanted to share that yeah that'd be great Danny go right ahead cool so as you all know the runtime verification guys received a grant and are doing formal verification of the Casper contract you always working really closely with them I rereleased the implementation guide last week with some of the updates we had made and contacted some of the clients I think we jumped the gun a little bit of
that because it's actually a little bit under specified in terms of the mechanics so we're actually writing the formally IP that specifies Emily what the clients need to do at fork this is we're finalists smaller implementation details and I expect you have the IP ready for review next week so I mean generally the planners have the runtime variation people form over normally verify we launch the test net with IP specification so that clients have something that tests against finalize the Casper contract they see anything that comes up with the test informal
analysis set block numbers release on tests main that generally a few questions I have is where C++ tests come into this the yellow paper and KVM in terms of like does that stuff happen you see plus Stephanie things are happening when there was an EIP written and then as the yellow paper and K formal specifications for those updated prior to the port or what politician here I'm working on implementing hi avian and I hide any right out of issue and this everything we need to do
and and and we're with Gail Herman and Piper Pierre okay great thanks for the update to answer a few of your questions Danny what generally happens is there's an EIP that gives the motivation abstract specification and implementation details and after that is produced then the KVM team in the yellow paper team generally take that EIP and then translate it and to pull requests towards the yellow paper and kab m in order to keep up with the EIP as developed that's my understanding Nick I think we've talked about this a little before is that how you understand it as well
yes I think that's a reasonable assumption exact Arif I though that it's the the it is this job is to keep the process moving not to actually write leaves yep agree and then as far as testing goes Demetri do you have an opinion on when something like Casper should start discussing with the testing team what tests to make I'm currently too focused on one those tests VR PC stuff okay that it sounds like me okay with you and the ERP is being normalized
well what time's the release is planned four legs yeah and how many mue a piece approved the Caspari IP is going to be one e IP whether it shows a lump anything else in that fork I'm that decisions beyond me I'd imagine it might just be Casper yeah so it's usually how these things go down testing wise sometimes tests are prepared well before the announcement of a hard fork but they get shirred up as we're announcing dates and stuff and giving timelines so for
instance during Metropolis we had tests developed you know over the past six months because we knew what he IPS were going in and just as the case with her sorry about Byzantium is what I meant we have Metropolis coming up Byzantium with that instance we had test cases made and some have a comment if you want to implement a new test and you test VR pcvue it will require at least a couple of major clients to support it and I still haven't finished as a protocol itself so if you if we really need to start the test for the Casper already I
think it's reasonable to work there all four months that we have working is high and there is and test each conceivably client so we just increment Casper changes and CP as we did for metropolis and prepare all the tests in the same format that you already have tested working and then everybody seems to be Highness this foreman and I just freeze my current work is air PC meters and focus on a Casper test and okay well I'd say continue your work until we walk more until we formalize the ERP and then we can shift that we need to yeah and maybe I will be able to
finish this New Testament in time before the Kasbah maybe it's just a couple of everything needs to be implemented and then every client should be able to work within you tests and I was thinking the last ten minutes about this and then I think I'm going to do kind of a new test for months and and general for most was a serum test because I see that state tests and blockchain tests now have such a lot of things that are common because the transaction being sent to the client stuff
I think it's reasonable to develop a new general format for the a serum test like nah no shenanigans is the state blockchain and VM kind of different tests just a single test format for all the possible tests that we could come up with you and it should be executable via RPC it's so interesting okay great sounds like we're a shirt up there and I want to make note that we're trying to coordinate here between you know the testing and the client implementations and the Kasper research but we shouldn't be rushing any of the research efforts unless absolutely necessary in worst case scenarios since you know we like things to be very very
assured to not break and not have any issues as much as possible so I think we can continue to do a good job of that it's been Edgington from the pegasus team pointing back to your yellow paper remark earlier so I raised a few months ago the idea that a IPS or two contain a pull request to the yellow papers before they are merged or accepted and I just wonder if that's relevant here I don't to derail the discussion but just wonder if they'd have been thought about or whether others feel that's a good idea they needn't been written by the author of the EIP there are others who can help with that but it would help I think with
the rigor of formulating a ip's yeah I think that's a great idea and yeah we had brought it up multiple meetings ago and I think we should continue to discuss it so yeah that sounds like a good idea we probably won't discuss it today like you mentioned but let's bring it up at least next meeting at the latest cool thanks awesome okay so as far as going back to the original topic of the ASIC resistance is there anyone else who has a strong opinion that would they want to discuss about whether or not we should implement something like that I think feed the proposed changes and that are relatively straightforward but
I don't think the current situation justifies a fork on and so I think we should consider rolling it into the future hard fall you know definitely agree on that hmm like this okay I definitely don't think that like even if we once too hard for the 836 or any good like it's any kind of emergency situation that deserves an arc even when bringing anything things ahead of schedule or like bringing or I bring an immediate heart fork ahead of schedule that also probably lets us know that we're breaking something as opposed to just probabilistically breaking it at
that point yeah okay anyone else have a very strong opinion they want to discuss so my take on this from a community perspective I've been talking I've been seeing a lot of discussion back and forth and it kind of comes down to the people who feel that it is actually as a security risk that they're not entirely sure how people who think we should do nothing and people who are very emotional about bidding and just are like down with bit main down with a six stuff like that I don't know where that comes from I think it's like a cross over from the Bitcoin community or something but but yeah so that's kind of what I've been seeing so far and for
those listening in who really have a strong opinion on this who aren't core developers you can do a carbon vote and you can do like an EIP on your own or do stuff in the forums and read it to kind of raise the issue more because if the community truly wants this to happen and hasn't got enough reason I mean we could definitely do that but for right now it sounds like the consensus of the court developers is that we should not not do anything at this time is what I'm picking up on can we actually agree on the conditions what would be like what kind of development would require emergency response so what would be the conditions for this to be a problem
that's a good point does anyone have any comments so what was the question what would an emergency response will look like so what would be the condition so now we said that we should that these these particular Asics which are probably just 2.5 times more expand 5 times cheaper per hashing speed are probably not much of an issue but I think an interesting and important question would be like what kind of development would require an emergency
response what case would say that there is a meet word transaction which does not actually which is not actually the case now so one thing to keep in mind right is that a bit the any ASIC manufacturer has an incentive to downplay the amount of influence that they have over the network because they know that the warrants won't stay out over the network the more political pressure there is gonna be at a heart for clim away so it seems to me extremely likely that even if like that like bit mean or whoever else when you know what eff to pool you know like some
you know I created North Korean government's like some people in Iceland whoever um even if they have 51% the chance that we will find out before they say they actually start doing a 51% attack is quite low so it's um yeah so because of that like I know I don't think that we are going to see flags that are kind of rather than actually seeing an ASIC and being able to buy and you know like someone being able to buy
it but less red than in actual 51% it's not already happening and so like it seems to me that like just seeing someone by any having someone buy an ASIC and being able to see it it's not a sufficient condition and a 51% attack actually happening clearly is a sufficient condition and they don't really see anything in bits like we in between there could be used as a flag so there are signals we can look for such as somebody promising to sell an ASIC that is orders of magnitude more efficient than GPU or a sudden uptick in proportion of mining power and by one particular poll we suspect to be
engaging an ASIC mining mm-hmm so one question is should we try to prepare by defining an alternate hashing algorithm and implement that and have it ready to go into hard work on a short notice and if we don't do that work my personal kind of intuition is that if we can just kind of form it off to someone to make a GPU version of just simple sha-3 then that could be from or I mean maybe not simple shot mean it might not be shot to be but just like any any hash algorithm then that would probably make
the most sense because like it's not a a bound and it's like very different and for the time during which that algorithm is there like it would still be yeah it would confer any kind of temporary benefit of making block headers much faster to sync but like ideally make sure to find ways to do that in parallel with all of our other work so it doesn't you know explodes the unemployed optimizations or exhaust resistance or whatever um I think that I have what I need to go back to the EEP and sort of
post a follow-up if anybody else wants to toss anything in feel free but otherwise I think we've got a decent picture of how everybody feels about this issue yep that sounds that sounds about right Daniel did your question get answered sufficiently yes thank you okay thank you I have one more question go right ahead what say we have FFG talk of a mind network of that has things is this do we consider this a problem for like security of the network you mean
yes I'm not sure hmm so oh yeah Danny if you could repeat the question real quick if we have a hybrid network where we have G on top of a network where Asics have now kind of taken the majority of mining do we consider that a problem um so okay in that case like as the protocol currently exists what would happen is basically that a 51% attacks can effectively prevents the finalization of new blocks but it cannot prevent cause a final but you cannot
break finality one simple fix that could probably like seriously mitigate the power of a 51% attack there is if we just add a consensus rule that's where if we had to the fortress rule that a had mmm like it should be preferred if it has a larger number of kaspar votes for the current epoch you would inside of it okay so what that would do is that would basically say that if there is some like if there's an attacking mining chain that refuses to include phone so then there's a good guy mining it doesn't move votes on the forks Chris algorithm will just pay for the good guy change and that should render attack like 50 even 51% minor attacks
relatively weak maybe that's like Danny you know worth kind of in the background thinking about it making sure other word that works doesn't introduce problems gotcha okay cool so we'll have Piper go back to the EIP I'm sure community discussion will continue for a bit and if it's still a really loud topic of conversation or things change we can bring it up next meeting any other comments okay the next topic is italics April Fool's joke to cap the total eater supply at 120 million and then everyone
took it seriously and so let's talk about it who wants to do this or actually a vitalik if you want to start can you kind of explain what happened as far as that ii per 1 960 goes for those who are familiar um so what the eat basically does is it says that we added to decide on some max a maximum either supply cap and i recommended once 120 point 4 million and it basically makes all rewards inside of ethereum so this would be current proof-of-work rewards and also it includes a commitments to be call future
rewards including you know i casper floating rewards like starting call um you know block rewards and anything like that all be proportional to one basically the maximum supply minus the current supply and so that basically means that the if supply instead of just going up linearly would kind of exponentially the the growth would exponentially decaying the supply would kind of exponentially converge toward the maxval at least until we introduced things like rents and our partial fee reclaiming in at which points you know and you'll will have a kind of balance where the supply will probably adds up being constant that someone below the max and points getting birds and points
getting created would roughly match each other cool but that raises the question that for now smart contracts have been pretty diverse in their way of burning eater when they wanted to for example they just lock the top somewhere unaccessible but if you have a limited supply that mean that would mean that there would be a formal way of burning ether that would actually remove it from the calculator supply like something yeah and like there are different ways of doing that so for example one way of burning supply that exists in the casper contracts is that if I'm in the task for contracts the if a fellow dieter gets get slashed
then their penalty is basically just stay inside the Casper contract as part of the Casper contract balance and so in that case it would be pretty like if it was if the Casper contract was the only thing issuing rewards then it would be pretty easy to calculate because the Casper contract could just be assigned you know a twenty million if and then it would set any rewards to be proportional to or 20 million the balance remaining inside of the contract if we want to do something more standardized that we could just do what based on you know exuberant ease by sending it to the zero address and then rewards I could potentially even be paid out of the zero address and proportional to the amount of money in the zero addressed or you
know so my part I personally think capping suppliers a bad idea because you can measure you can fund security either through inflation or through transaction fees and funding through transaction fees encourages holding and the discouraged and active ecosystem which i think is both a bad idea in general and also can lead to a sort of a deflationary spiral where costs go up because transactions of here and that leads to fewer transactions and so forth so it's really worth noting right that like the transaction caused some costs in in aetherium are in the long run not
proportional to um ether fees right they're proportional to a supply and demand and so like in general it seems like they go up when it goes up because when eastcoast up like demand an adoption goes up but really if the price of eath were to go up for some exogenous reason then which would happen if it which in general is likely to happen if any kind of proposals implements that that reduces the expected supply then that increases the price without increasing adoption and so it is quite likely that all just lead to reductions in the in this transaction fee that people actually pay so I I don't see a reason to expect say in the long run for there
to be a kind of a hard winking there in other about deflation eerie spiral from the point of view of like macroeconomics that stuff tends to apply much more when like first of all the thing that you're is deflationary is the unit of accounts for an entire Iike for an entire economy and second when like it's something it's something deflation II read that kind of a long-term sticky prices are being set in and I think that you know in the past it was definitely the case that ether gas prices are stinky but now you know what we have said Amex key calculation for pretty much everything and so I
don't really expect ether prices themselves to be sticky and what EFA's hyper volatile to begin with so I don't actually expects will be even be able to notice the difference Mike price movements as a result I didn't mean deflationary spiral necessarily and the traditional economic sense but in the sense that and if we assume people adjust their behavior based on how much transactions gonna cost and if we assume that there's some minimum number amount of fees that we have to pay in order to secure the network then a high transaction costs could lead to fewer transactions which leads to higher transactions notice that I'm not necessarily suggesting higher
transaction costs right like well okay so I'm so I'm suggesting well it's so first of all like the mean place that in the long run the kind of the money would come from in this change is from a lower revenue page to us to a participants who provide security so in the shirts or miners and like in the long-term Casper validators right like in the long-term I do think that no a Casper validator revenue should be roughly equal to DM amount the people in transaction fees that's there's there's no closed-loop
Slayer though is that because we presumably there is some level of identification we need or your certain level of staking we need to secure the network effectively and there's nothing that ensures if a transaction fees will match up to that there's no minimum there's like a level right like so like basically if we have a smaller reward then you know instead of like 20 million years taking we might end up having 10 million he's taking which on the other hands though like there is a risk that like if we have a cryptocurrency which is who is which is means inflationary then that could lead to its value
dropping which by itself leads to a less capitalistic securing the network so it gets I mean it is like it is kind of hard to like figure all this out in the long run but I know like I personally do think that there's evidence that the e/m like in that basically a transaction transaction a few levels are capable of providing enough revenue it's who was secured to a secure ablution and in the long run if we're if they're not then like there's the question of well how about how
valuable is this system like is a system that we're building in the first place I mean personally I I don't think that transaction fees have to be the thing that supports a blockchain you know if we need some amount exceeds a day of money to incentivize miners or stay cos you can take that from inflation or fees and personally I think it makes for a more useful system as we take it for inflation because it imposes the cost on everyone who is invested in the system just those who are transacting and it's also just transacting right so I used to think this way but the problem is that like as white keeps pointing out right
that if do that then like basically every year is he 20 token becomes a better store value than ether like if if becomes this unique token inside of aetherium that has the ante privilege of being being inflated to pay for security expenditure and you have the ability to just like print out ERC twenties on top of aetherium and like market them and these tokens don't have this disadvantaged then you know like it may well be the case that you know like eventually there's going to be this tragedy of the comments or even though eath is necessary for now for network security no one wants to support youth mmm that seems a bit of a stretch like 2% a year inflation to 2% of 2% of your inflation
is a lot it's like the difference but so think of it this way right like I believe it's the case and that like in the long run people expects to be able to earn something like 4% a year returns reliably from the stock market and if you take 2% off of that then what you're basically saying is that the amount of money someone if someone needs to retire goes up by a factor of two because you go down from 4 percent to 2 percent so in the context of you know you know a financial market returns 2% it's a huge deal ok so do other people have any comments on what Nick and italic are
talking about yeah it sounds like let's see yeah it sounds like we can bring this back to the EIP I guess does anyone have an idea of a community sentiment cuz I haven't been able to pick on that pick up on that as much from what I've been able to see it seems broadly in favor of supply kit hmm yeah that's what it seemed like on the EIP and in Twitter and reddit but
those are only three metrics see any point in discussing technical constraints because we currently have no consensus values for total issued ether for instance that's a good point what would it require on a technical level so my personal preference for implementation is that we just basically pre mine like 100 max cap - currency supply into some particular address and you know this could be address zero and we just basically say that whenever we're paying rewards we subtract the balance for me from that amount from from that account and then that accounts
our meaning balance is basically by itself just used as the constant multiplying factor that's roughly three orders of magnitude simpler and what I was thinking so sounds good is like city to the Kasparov contract to have to calculate what percentage is coming from reward versus the base but that's not actually that complex okay cool so it sounds like there's actually a good amount of support around this this would require a hard fork so would this be a something that could potentially be
in the troposphere possibilities one of them is like if the community really wants it then in my face you have metropolis the other possibility is to just wait a bit and incorporate it as part of the XS for F of G change yeah and that will depend on if we have Constantinople before Caspar FFG agreed would that be a separate that'd be a separate EIP I would just be in tandem with F G yeah someone would have to champion that and because I know the
talaq wrote or vitalik are you actually currently championing champion that or D are you kind of waiting for what everyone else wants to do and someone else to write an EIP um I'm kind of waiting on I guess like wait waiting it to see more community feedback like okay sounds good well let's just scrap this for now and bring it up next week once we have a little bit more feedback from the community post meeting okay so the next agenda topic is AIP process updates we'll go through that real quick basically Nick made a really badass site called VIPs dot aetherium org that is
automatically generated using Jekyll Nick do you want to kind of just go over that real quick and also your automated bot sure I think I gave a brief overview of the site the last two lands but the basic idea is that it takes all of the amount down files for the heaps and automatically indexes them by type and category and generates individual pages for them and so as soon as a new leap to the repository and it gets updated on the site with github automated page builds I've also with the help from the coach Oh a continuous build using Travis their chicks heaps and pee out of the repository and the PRS for syntactical
energy and so we can take some load off the editors and make sure everything's valid they've found a bunch of issues with the existing ones fixed of course any time you'd ever build something slips through and in general I'm trying to work towards set up where editors merge drafts sooner and quicker and then make it easier for authors of drafts to to continue working on changes until they're ready to take it to work or divs or a standardized if it's not a quarry so that in mind I've also written a bot that keeps an eye on EP RS and when it sees one that is just only of its two existing IP drafts it will allow it to
be merged if the author of the draft or one of the authors of the draft submitted it or if the one of the authors of the draft approved it using a tour request review and so that means that for trivial changes or changes to drafts they no longer require manual approval by an editor they could be automatically approved and so any suggestions on remaining the process are welcome I really want to get it to the point where open Piazza will require action either from the submitter or from any that's a rather than the current situation where drafts can survive indefinitely and also to get it to the point where drafts of misurkin github URI for their Adeeb almost immediately
and that's it for me thanks Nick I also wanted to point out that there is a pull request 9:56 that Nick made to kind of clear up the draft process so if anyone wants to give feedback on that it's basically making the EIP one less ambiguous with how drafts are handled and it's getting a good amount of support except for from some people who think that they don't want to take out the words not keeping with the etherium philosophy so that's one of the points of contention so anyone who wants to chime in there feel free to join was bringing up the other issue is debate between mostly nicely between myself and Greg Colvin
about whether we should member deep drafts immediately or only when they propose past the bath stage I wrote the book with the idea of either working with either system the feedback I meant appreciated and for anyone who wants to insist on keeping the in keeping with the etherion philosophy bit I would invite them to submit a description of if they're in philosophy that they can get a hundred percent approval on and if they can do that yeah ok cool anybody have comments okay the next item is research updates we've already heard from Danny about some of the Casper updates Vitalik you have metallic and friends
who are your friends in the room with you again young ash away and Carl cool so is there any other research updates worth mentioning metallic and friends or Danny I guess on the sharding side we've been just looking at like more ways to make the like the entire setup of like how I of how collisions work and alcohol use get verify it's like somewhat more efficient since no panda supports a implemented a bunch of ways but like so far it's still unlike ideas information I mean I expect I expect the
implementation algorithm to end up becoming simpler after the end of all of it cool so just to give a quick research update prismatic labs has started recording their meetings and they've also been releasing blogs on their updates they're the ones who are trying to incorporate sharding in together so anyone interested can look that up and then James Ray one github is doing drops of diamond which is a rust implementation of of Casper I believe and he's working on the SMC and Viper right now and someone else is working on the proposer and call later to interface is a charting implementation oops sorry
you're right it is charting thanks yeah so he's working on the SMC and Viper and then after that he'll do it in rust so I don't know that's beyond my knowledge but that's what he's doing I think that's it for research you know just to add Pegasus to your list of people working on shouting with us quickly they on the each research site of the current proposal around proposes and Co laters metallic scissors have changed we're waiting with eagerly to find out what the new model looks like so you know that would be great thanks Ben okay so if that's it for research the
next item is metropolis it sounds like we have some more things that could be EIP is especially if we do that either supply cap and if we were to do that before Casper we could include some of the other smaller entities we've been wanting to include so that's a possibility now does anyone have any other opinions after last meeting thinking about it about when metropolis should be or the second part of Metropolis Constantinople should be or if it should even happen before Casper cool yeah I didn't really haven't updated that much of an updated opinion either except to say that the community
is kind of some of them are seemingly upset that we kind of implied that Constantinople would be done by now but that it's not and so they see that as us getting behind or not implementing things fast enough when in reality it's just a separation and didier like basically separating concerns and making sure other things are priority including some of the research topics implementations so anyone have any comments on that right cats purr and sharding are probably the most important things working on in terms of works already and those seem like there to be there
enforcement part of Metropolis so we are working on the most important stuff you working on oh we could actually cancel metropolis if we were not metropolis constants in Oakland we wanted to there were some eeap's that we wanted to get in though so I maybe those could get in during the Casper Fork I don't think that would be too difficult to kind of bundle them all together any thoughts on that anybody okay cool well I'll put it on the agenda for next time and we can bring it up again because there's not like a super rush on it or anything to bring up Constantinople since no one has a strong
opinion either way okay we're gonna zoom through client updates now let me start with Jeff is anyone here from guess that can speak speak to any updates or important news yeah so we made a release ten days ago containing some and denial services it was a security release but otherwise nothing bayonets the next release will probably be containing some more fixes to which improves the block processing times with up to 50% yes I
don't so much just report at this time okay thank you offer your Frederick do you guys have an update for parity yes we : to neighbor wasn't smart contracts been pretty smooth and now there are some first contracts deployed as we have we we had some issues with boxing and edit now like some kind of walk barrier to the clients users can like configure a minimum block to war to the issues that many outdated snapshots out there and
the major major annoyance that people walk to like local 4 million and tends to have to synchronize a million blocks yeah probably that's it it's that and actually doesn't sync normally like it forces a warp sync so usually like there's been a problem of you try to warp sync it fails or it can appear with a snapshot and so it reverts back to normal sync and that will take a week to finish and people aren't really aware of this so if you set this warp barrier now like actually force a warp see thanks parody C++ aetherium Paulo yes quickly so we separated the AVM C
which is called client vm connector API to separate repository and we are in support for that city PA cheerio to Kira and to EVM JIT and Andre is working on some network stack improvements inside the client thank you anybody from Mikhail from Harmony yeah there is no major updates since last release keep working on Kasper and playing in the next release now one of the things which will different could be included is
proxy be fine tuning because during last profiling of import I know I notice that reading database reads are taking about 40% processing so and I'm pretty confident that it could be improved by Justin rocks to be options and parameters so yeah that's all I guess no okay thank you does anyone from aetherium je s or the e azam team here that can give an update on either of those projects hey Hudson this is Lane I can speak to you awesome
can you hear me yeah I can hear you great great I'm in a bit of an unstable internet connection I'll keep it super brief not a whole lot to report we've been doing a lot of work on EVM to azam which is sort of spyler which would allow us to continue to run legacy EBM bytecode in kind of a la CIMA world and so our current kind of task there is getting state tests running via a VM to Wasson we've got the first few passing which is pretty exciting we've been fixing some issues around things like endianness and then I'll just read here I've got an update from Everett Hildebrandt is working on K EVM he says he's been going back and forth with he ohe about removing some tests from the vm tests to make it only test core vm infrastructure it's a good
step in the direction of separating the etherium specific stuff out of the EVM in the same way that you know the e separates the etherium stuff from wasman he was him ok great thank you turbo guess they posted an update cuz Alexi wasn't able to make it working on reorg capability and he rebase go aetherium as of the 2nd of april he'll be talking about turbo death at IDI con so if anyone's going to ed con you can see a talk on that so that's turbo get the bigger update is actually in the agenda if anyone's interested next we have consensus Pegasus then our Daniel do you have any
other further updates no news on client development at the moment only that it's continuing a pace and hopefully relatively soon we'll be able to probably can keep you updated more more closely awesome thank you and then finally Trinity which I think Piper had to leave early but he did mention there are no major updates there did I miss any teams or any projects or research things that need to be discussed okay we're just hitting an hour and a half so I had on the agenda that if we had time we would get to e IP 908 reverbs for
clients and full nodes validating transactions but we're just hitting the max time for the meetings so we'll have to push that to next time at the bottom of the agenda or actually in the agenda it's item number 10 if you all could like read that and get ready for next meeting we can have some opinions on that one and and kind of talk about some of the ideas other than that thanks everybody for joining today we'll see you in two weeks I might not be there I think it'll be the first chord F meeting I've missed since January 2017 but I think if I'm not there lanes gonna be helping out so go easy on him and we'll see you in two weeks bye everybody
thanks had some guys think [Music] [Music]