EthCC 2: Boris Mann

welcome to the ECC first edition of the eath one point X roadmap aetherium one is the chain that you know and love and we need to maintain so that our network doesn't die are we excited so basically what we've done is Lane over here and myself Boris have pulled together a few bits and pieces to try and share what is happening with the eath 1x roadmap the ýstanbul hard fork how this all works and what we think are some of the things that are gonna go in we're gonna walk through this presentation it's actually a slide deck that's in hack MD Lane's done some edits I did a few things it's available there may be edits from random community members in here because it's it's open to world writable right now this is interactive please go ahead and put your hand up and ask questions as we go we're gonna try and be very explicit about does everyone understand does anyone have any questions and see where we get to we're gonna gather any questions that people have so Lane and I know a small handful of things but mainly we know who to talk to to get answers to other questions and how to share them so that other people can help answer them and use hashtag eath 1x on Twitter to ask questions yes sir is there a URL for this hack in the document that we can have if you go to the etherium magicians forum it is linked from there and if you go to twitter.com slash be man my twitter it should be the second tweet from the top right after a picture of a French pastry and Lane all L Rettig to T's will also tweet it again okay shall we begin thank you for the horns up there Justin so what is the eath 1x roadmap is the guiding question for this conversation this actually started I would say in the eath magician's gathering in berlin where one of the first times people said what is the road map who's in charge of it where do we write it down and that discussion has really continued from then with be both eath 1x and eath 2 why it's important what are we doing how does it tie into eath - and who's responsible for it so what are the upcoming Hart forks so Istanbul is the label for the hard fork that's happening this year in October one of the things in scheduling the Istanbul heart fork was hey let's move to more frequent releases let's do some planning and let's do either 6 or 9 months as far as I recall from the back and forth the discussion was pretty much like let's do 9 and then we'll see if we can do six for the next one I don't think we're far enough in planning right now to know exactly where that's going to be but what I tried to do is is just think about like what is what is this stretching ahead what does this look like so at six months so if we do one in October of Istanbul the next one after that would be 20 20 April 20 20 October if we do nine months we're looking at July and April I think this is one of the first times that were actually for me it's super weird to put dates down like 2021 cuz that's clearly some sort of crazy future date the 2020s what even what even is that I think this is where we'll probably get into some interesting questions so May 17th so all of these dates were picked to likely be either like a Wednesday or a Friday like the projected date for the main net upgrade that's a Wednesday because clearly shipping anything on a Friday is a bad idea May 17th is the next date that we need to care about and it's not very far away so it's the hard deadline to accept proposals which means people have to write an e p-- an aetherium Improvement proposal submit it to the eep repository have some discussion around it and generally signal and saying I'm planning on trying to get this into the next hard fork July 19th would be the soft deadline for major client implementations as far as we understand right now the rough rule has been if you want your EEP to make it into a hard fork you need to have at least two major client implementations so that's where that date would be critical mid August would be actually doing an upgrade on one of the test debts with October then being the objective date for Maine an upgrade this originally came from a core devs call and ends up in the notes in the etherium / PM repo kind of buried in a comment so I pulled it out and I've been maintaining a couple of pages on the etherium wiki for the Istanbul hard fork and other dates in the in the in the roadmap so those are visible and an easy one should be easier to get to then uh then along github you're all questions islets clock go ahead how would what the some at soft that major client implementations means it's already in and running or like what would be considered it's in that kind of makes sense say it again but the just keep going so it's a good question it's a good question so I think your question is so what defines as its implemented so that it's so that it fits the requirements of being able to be put in I would generally say at the very least you would need a pull request to the major clients so code that works in the current version of a client that merges cleanly a for the eep that you want to do right so that would be in the goth repo and the parity aetherium client repo having a PR at the very least some of these are loosely undefined so we're having this interesting discussion exactly around like well what does it mean I even have a question of like what does it mean to have a proposal could I just like quickly write up an deep and be like I wrote an e is that cannot be go in now so it's it's a process where we're actually tightening down some of these things a little bit and then just as a bit of a follow up who do you consider to be a major client I thought that I could easily get past some of these undefined things in the past major client might just get written rewritten as death and parody obviously the Pegasus Pantheon client is quite robust these days although I don't think it's running that much on main net yet kind of it essentially means not some random research client that doesn't really run maenette ever fair what's that well won't make it in if it doesn't run on me net there you go so if you quickly write a new implementation maybe any other questions yeah hi so I just had a question really the testing I know in the past inflammation of to implementation of test cases has been a huge bottleneck under this proposal would you say that it falls to the implementers ultimately to implement comprehensive test cases for proposed AIPS obviously with help from the from with buy-in from the testing team and help from people who have domain-specific knowledge in that area or I mean what I guess how do you feel about that so one of the things I've done actually at that Istanbul pages there's a section at the bottom for proposals a proposal I've made in there is that this these dates should be extended with a security review I think testing is another perfect one we're having test implementations done whether we work together as a community and centralized testing or we ask that the client implementations have tests that they can show of past is a good question I would leave it open but I would also probably put an asterisk in there that says you know the suite of tests that we've written for this eeep code passes on a regular basis does that seem fair as a way to to do it yeah I would say that seems fair I guess and this that yeah everything you just said seems seems seems good but I guess as somebody who's worked a little bit with testing and seeing how when you when you only have a few people making the decisions and no because you know testing is Ana glamorous job the software can take you know it it may be hard for people outside of the small clique to to participate so I guess my point was that it'd be great to get more testing more community buy-in I won't waste more time so I I totally agree yeah yeah I mean so currently it is that yeah you want me to okay so currently how tests work is there we right cross client tests that are represented in JSON and I mean I won't go into the details of exactly how test case works obviously but and then to actually fill the tests meaning to actually take to to actually create the test cases we need to use CPP if we use CPP etherium and specifically test eath which is a which is a which is the tool I was talking about that the testing click has the that a select few are rather familiar with and to the outside world is a black box test Eve and I mean obviously there's there there's different kind of you know those are those are only unit to state tests or unit tests right so there's fuzzing I mean that's kind of a high-level yeah that yeah that's that's what that yeah that's what these unit tests are their consensus test for new features but that that's the state of testing right now late lane I also don't want to take over your talk so you know let me know if I'm like if this was a circle idle to do a circle I'd do that so let's spell it out right now there's a centralized aetherium foundation founded team that runs a single testing mono repo for all of the aspects of aetherium it is lightly connected to various specifications many pieces of aetherium are under specified thus it is very hard to create tests and very little of this is automated and the skills to do this are in a very small group of people who mainly need to program C++ and some JSON is that about right can we let's turn this into a question or ask for help because a lot of this is just surfacing issues and I'm gonna say one of the things that we need to do is identify timelines and effort needed for testing is that is that a fair statement of summarizing and we know that one of the things that is needed is more testing resources if we expect to ship more upgrades yeah I strongly agree with that whoops this is way louder than I thought it would be so so my quick question I mean you said something gentleman just hey Jerry one since you said that sort of really got my goat real quick is how do you do a test on consensus via unit test right don't you have to be running a network with like I had a genius set of notes to like actually determine if you're complying with the real consensus environment like how do you what does it mean to say that you've done a unit test on consensus I see I see Jordi shaking his head angrily and I would love to give him the mic so he could respond because I just don't understand how that makes any sense I told you we needed more mics yeah I'm supposed to not leave the lines um I don't know if this will help me help it make sense right on one hand we have a test suite that does test consensus within a simulated Network I'm forgetting the name of this thing but Peter actually wrote it mm-hmm hive and that's one I know that's being used for some things also there's a new test framework being worked on by the by Python by Piper and there's a DevOps person helping them a Nuge also I know Casey I'm not sure how much Casey's involved with that do you know okay so there are more resources being put to bear but I do believe that they intend for consensus test in a simulated Network involving more than one type of client so yes I just mean very concretely what does it mean to do a unit test against consensus right I think the answer was the hive environment where they do is simulated it's not a unit test I agree actually I have a question is there a written down test plan okay like done we've parked this entire thing one of the things that we need to accurately make a net network I've grade is I have a written down test plan does everyone in this room have rough consensus that we would like a test plan written down any disagreement perfect so probably you don't want it written down a plan for testing that is written down I have a very low bar Pavel oh no I'll put it better something that is written in a document that I can get to you with a URL that does not end in a get er Channel what's that perfect now it's more like coming with an answer because we're building dezer minds as a following the major clients the unit tests are actually unit tests because the way you test consensus consensus is practically are just checking if the hash of the next block is the same as expected so can define very clearly the test cases and see if you arrive at the same hash the separate thing is checking if the branches are followed the same way so if it split and that's when you need some kind of testing of the network if everyone knows the same blocks from the block propagation but the unit tests are really there and they were super important and whenever we have a heart for collect from for us following the major clients at gaff and parody this date of having the tests to to run everything this unit tests to be ready it's very important to see how if we already already or not perfect we can hear Rick I'll move down right that solves this whole problem so so it sounded to me from your description that you were running two separate unit tests with the same data in two different code bases right okay so that again not to be pedantic but that's not a unit test right that's yes in two different test Suites so that is the answer to that question right you you weren't using one you weren't using one code base to verify I mean this is like a semantic thing right if we have multiple clients and we're trying to get consensus across multiple clients then we necessarily must be running mole all tests to get that consensus confirmation right and that has to be and I'm just mentioning that in this very pedantic way because it goes into the test plan right when you do a release you can't just say oh we got internal consistency in our repo so we're not gonna fork okay so you're not gonna fork from yourself that's awesome but there's other clients and you need to have some sort of cross test across those repos to show that they're not going to fork as well like that there's going to actually maintain consensus across the clients yeah yeah okay yeah thank you that was awesome I'm gonna go to the next slide okay I'm publicly signing us up Alex so 233 describes the formal process as has just been discussed from maybe making sure that there's a test plan Alex and I talked a little bit that that likely could use with some upgrades so the eat process is where we write down what our plans are and how they work and so this e to three you can visit has the details right now Alex and I are gonna do some work to look at that and improve it and implement that as part of this next Istanbul Hartford process did you want to add something about this right now no good we will do work signaling eat 1679 is the Istanbul hard fork meta IP so it's the place holder that says these are the details around Istanbul one of the changes that Alex and I are gonna propose is that ahead of the hard fork anyone who intends to propose and eat makes a pull request against that meta EEP and we initially place it in a proposed section that way we can track changes through github and use the processes that we already do and make very visible which eeap's people are committing to work on very roughly this is the process so proposed and EEP and the way to propose an EEP is to go to the eats repo take the markdown template fill it out submit it get it get it into draft mode draft mode is only about making sure that you have the markdown correct and you know some light checks to say yes this is the right format get them to last call implementations bring them to court have to move them to accepted signalling that they will in fact make it into there I put the piece about inflammations in at least two major clients in that sometimes code gets written as part of the process of proposing eeap's where there is some code in flight kind of in parallel with some of the rest of this process does this make sense did I get something wrong does anyone have something to add to this outline awesome now we know how to make eeap's this January end of January in Stanford there was a core dev meeting about 30 or so people attended I think organized by Joseph Chow from consensus the two major topics were state fees and he was him on February 6th I helped host a webinar where we went over some of the things that came out of that Stanford meeting there is a really great video of that discussion that is a really good way to get up to speed with a lot of these topics and we asked a bunch of questions and I think it was a pretty good format and in many ways what we're doing here is doing the same thing again so that people have an opportunity to to ask questions so definitely look at that Aleksey also responsible for turbo GAF work has taken the lead in research and planning on state fees as we know or perhaps you are learning for me in the first time is aetherium state is growing to unmanageable sizes and it's gonna hit a critical point in about two years critical meaning that nodes will have trouble syncing because of the size of the state yes nodes currently have trouble syncing to years from now they reach some theoretical limit that will most definitely not link that two-year estimate is based on kind of eyeballing well this is how many people build apps and built apps in a particular way and this is how many new people so if we think that more people will continue to build on a theory 'm in ways that use state in the way that they have in the past we may have less time but we'll have lots of new users good news bad news there are better images of this but I just wanted to pull this in look at Alexi up there with his little mop head he's amazing what Alexi did is is initially I caught a glimpse of this chart and I said that is the most confusing chart I've ever seen in my entire life and then I actually read it I'm like oh this is a really good way to represent this so Alexi as you know proposals are in flight but basically has a bunch of different components that go into upgrades to aetherium to the protocol to how things work in order to make some fixes around state fees and pruning so what he then did is decomposed it and said which of them depend on each other which of them can we do in parallel and which of them do we have to implement in a hard fork and then we have to wait for that hard fork to pass and then we'll get to do another hard fork so what do you came up with is a potential timeline that implementing state fees will take three hard Forks what you'll now see this loops back around to our timing for hard Forks that take you for either six or nine months so that way we can tell how long we have to implement all of these things does that make sense and as you can see on the side there there's a whole egg Lexi's got a whole presentation around this where he walks through each of the proposals without Alexei in the room we can't go into the details I Rebecca recommend watching the video I recommend reading the presentation the place where we have this slide deck linked on eath Magicians is a great spot to add questions and also answers ok is there anyone in the room that wants to say a few words about state fees in more detail oh.just epicenter recently did an episode with alexei and he went all over this and it's a great resource as well perfect the epicentre podcast yes I'm liking my own thing here but yes great if if we can make sure that that gets linked into into this forum thread that'd be fantastic yeah just just really briefly it's a fairly controversial topic I don't completely get why I mean I get that people are people feel that maybe there's some implicit social contract whereby you know you deploy something to aetherium and you expect it to always be there that's really nice but it doesn't matter right because it's an existential question right and like nothing else really matters if we don't fix this and etherium dies in two years like nothing else really matters so we need to fix it it's really important get on board hi so for state peace I understand that the kind of the necessity is that we don't have a chain that's kind of like just filled up with I don't know probably things that have been deprecated but it introduces kind of a new question mark in development by having state fees and we can we can seriously break some of these contracts that are relying on other contracts and and kind of ruin some of the guarantees that came from static analysis of the contracts beforehand yeah I believe state fees represents basically a change in the user agreement and I believe it represents a new series of aetherium maybe not as dramatic obviously is to oh but I feel like state fees is one oh and what we're on right now is zero right and if you can see like all the all of what it requires all the steps I just think it's so big this isn't an upgrade this is this is a whole new series of etherium that makes the theorems until we get the tool I mean that's just my general impression about it I want to see what if people feel that way if it's on that level yeah being that too over requires the main main net I'm hoping that main net will be active when toooo comes around because what's going on right now with finance there's going to be some new apps that take off and there's you know there's it's is it going to be as big as the ICO phenomenon I hope so because that's that's activity that's success will success generate conditions that make it happen faster than two years that's what I want to know I don't know how to predict that someone please can correct me if I'm wrong but my understanding is the beacon chain depends on the main chain running and will continue to depend on the main chain running into the indefinite future so when toooo arrives OneNote does not go away unless the spec has changed since the last time I studied it my understanding is the only the only place where the beacon chain relies on each one is is just transferring ether one unidirectionally from main chain to the beacon chain so in that sense it does it does because you have to be able to move value over from eath one yeah if it doesn't have value on the main chain what's the point in yeah I agree with that um I think we're the yeah we're going to have the deposit contract but we will depend on on one for those deposits until we hit the state execution phase which I believe is phase two which would be bringing you awesome online we can't you know we obviously can't dynamite the eighth one chain right we don't have kind of like that level of control so it would continue to exist indefinitely yeah I second that that's why we're here and that's why eath 1x is a thing right because we all recognize that we have to keep a theory I'm alive and it's in some form right until we have eight to two more really quick points especially in response to your point Joe and then I'll give you back the mic the first the first is I agree wholeheartedly with what Jaime said a moment ago like if theum is in beta I'm sorry like I'm sorry but if you built something you know and it blew up and there's a lot of value and people who are lying on it it's a beta product it's always been in beta and we need to get it to like a 1.0 and it's not a 1.0 until it's stable so if you have to make breaking changes I'm sorry but you have to make them that's the first point I want to make the second point is it's never been contemplated as far as I know making how do I put it like like even if we do state fees if we if we start removing contracts or accounts they can always be restored I want to be very clear about that that's part of Alex's plan accounts can always be easily restored if they're cleared if the dust accounts are cleared which is part of the plan and contracts can also be put back in place even if they're cleared okay so that nothing's going away permanently there's still immutability in a sense you can still replay transactions and and the stuff that was there is always there it's just what's your definition of immutability that's all a totally non controversial topic yeah so I think that's a really interesting one so again just echoing that that state fees you know there's a ton of my first app things that are sitting around taking up space there's a bunch of calculations around what exactly is on there what stale there's already some estimations of things that haven't been touched in years that would save this much space and those the ones that are targeted and they can be revived or rehydrated in certain ways and this multi plan thing slowly goes down adding these things until the very end we know what the variables are at X since account contract Y has been touched then we will dehydrate it and we will rehydrate it again you know there's already changes in language to try and make it clear to people that this isn't as scary I think what Lane is saying we really want to make sure that people understand why this is being done that it's important that it gets us to a space with sustainability with eath 1x running essentially forever and that's the reason and we want people to be engaging and asking questions now so that they're comfortable with these changes as they come make sense I realized that I was misunderstood Greg I think that aetherium 0 if you're IAM and aetherium 1 we all continue to run long after a theorem 2 is released so that's just my thinking about it is that what we have now will there will be people that want to keep that running so we upgrade to this to Alexie's proposals and it 1x and then that will keep running and I'm not sure how you deal with that in terms of the cryptocurrency because now we have three crypto currencies so I'm a little lost on maybe I just zoned out for a second as to how we get to 3 I counted two very clearly there the theory of zero where we're at today and you're saying atheneum one is Alexie's and then that's has its new token and then we have a third token when we go to two okay so my concern and within the narrative that you just described is there's no clear what is it that binds adapt so let's ignore the existence of developers for a moment because they're dows and what-have-you yadda yadda yadda so let's use the dap as the construct what is it that's going to bind the dap that was written in aetherium zero to aetherium to like why are we talking about the why don't we call it like happy monkey chain if there's what's the relationship and I I think maybe like a high-level meta thing I think that we're all here basically because of like mimetics right like we believe in the etherium narrative and so if the only thing that literally the only thing that carries over from aetherium zero to aetherium 2 is the narrative that may be sufficient but we're also a room of mostly engineers who probably find that revolting right so there has to be something actually binding the user the dap from one network to the next network to the next network and if we're not making these additional networks supersets but if we're not actually having the entire state of aetherium 0 represented in aetherium 1 and the entire state of etherium 1 represented in aetherium - it's like a shard or what have you we're we're in a we're in a kind of almost we're making a crisis out of out of for no reason so I think that we should in these sort of discussions we should be considering this as an alternative or as a hypothesis I think I think that's a big thing where I haven't heard from the earth to plan a concrete statement on on this but as I understand it the eath 1x becomes a shard in eath to where it has the same issue as all of the other eighth - shards of question mark around cross shard communication is that a fair and accurate way of saying it but it's undefined that's okay good go ahead someone tell me who knows for sure is you become a shard that's new to me so we're still I should say it's still being figured out it's a bit of an open question around exactly what happens to eath one after e 2 is running and we're past phase 2 and it's usable it's creating value etc I've heard three concrete proposals and this comes mostly from from Danny who also spoke about this on a I think it was a zero knowledge podcast recently so listen to that if you want to hear it from the horse's mouth the first is we just leave the existing aetherium chain to run and do its own thing it doesn't it doesn't cause any harm as long as as long as we are able to continue to finalize it so so the first thing that's going to happen in phase zero the first piece of value that the etherium two gives us the beacon chain gives us is it's going to be finalizing etherium one which is pretty exciting and so if if there m2 is able to participate in the security and finalize the blocks on on aetherium one then what that means is we can drastically reduce issuance okay that's the key requirement if we're able to drastically reduce the issuance on eighth one then we can levy --the one to just do its own thing and does nothing else needs to change that's the first option the second option is it becomes a shard as Boris said with all the challenges that would go along with that now the the complaint against having it be a shard is that it would be different from all the other shards in one special way it would be running a different state execution engine which may be kind of messy and so the third option that's on the table is somehow write the details are a little fuzzy capturing all of the existing aetherium chain and putting it inside a smart contract on a shard somewhere on aetherium - those are the three options on the table does that help clear things up right down so people can read you perfect thank you so just briefly unless as Rick said by some way but either by moving or surrounding it's possible if you have you know possibly one business I'm working in intends to build a billion-dollar system on aetherium if they are not able to move their billion-dollar system easily on to eath 2.

0 and there will be other such e 2.0 basically is a completely different thing and the only thing it really has in common with eath one is that it owns the etherium trademark that may very well be the case but I think that's exactly what Rick was saying hi I just have a question about the schedule the forks but the narrative I've heard is one for two for Keith too and I'm seeing Fork one for two for three this is the eath 1x chain it has nothing to do with e - right right that eath one has three Forks and then we move into eath to land or no none of all those these are the three Forks to complete Alexie's state c implementation at that point the etherium chain is sustainable and can run indefinitely without blowing out state so then what what i've heard of there is as us having two forks and then if two shows up but that seems incompatible with that is that's where I'm trying to get clarification so there are there are no dependencies of each yuan eath one not not technically dependencies but the narrow that they're like we'll have one release another release and eath twos coming in two years or so or something like that it's or unclear how long the roadmap is for you - again no dependencies upon eath one on the part of e two they happen in parallel we don't know how many hard Forks there's going to be an eighth one but again with one's gonna we intend to keep it alive as long as necessary so I would say it's probably gonna be more than two and one more thing while there's no dependency on eighth one we actually state rent state fees whatever you want to call it is a great example of one of the pieces of research that 100% lies to eath - yeah and so the hope is that this would be rolled in - it's close as possible to the form that we're figuring out three things that make sense so so we need to fix this for each one and this exact same thing gets implemented on a per shard basis right so that's it's more like the other way around oh we've got this running network that runs today that we need to fix and it turns out that that research and work is forward compatible which is a word I'm gonna start using to make people feel less freaked out yeah with future work that we're doing on e2 as well shall I move to the next slide yeh etherium flavoured webassembly insert Lane would you like to come down here and read this slide look you said the link is public so I hope Dean or someone hasn't gotten in and trolled us and changed things I threw this together really last minute I'll breeze through it I know a bunch of most of the e azam team is here in the room with me I don't know if you guys had a chance to look at this but like literally just raise your hand if I got something wrong or left something out because I want to make sure this is accurate so super brief background the project was initiated in is this right Alex 2016 by Martin BC originally who went on to build this really exciting execution framework called premiere for the Definity project built on the early work in parallel Alex and a bunch of us have been working on he was him within the etherium foundation it was originally intended so it's we've kind of come full circle which is kind of cool it was originally designed to be rolled out on the main net and then we found out if 2 is coming serenity is coming and the idea was let's push all the innovation into eath 2 and then we found out in June that eath 2 is going to take a bit longer than we expected so now we're kind of full circle and now he was him is back on the table for eath 1 as part of the 1x roadmap which is what we're talking about he wasn't was originally a passion project a side project that Martin and Alex were working on but as of about a year ago we have proper team with nine people on it I think six or seven of which are in the room here so we can answer questions we the biggest milestone to date is that we launched a public test net at DEFCON last year and we did a big workshop there which is very exciting so is our test net running I don't know it should be it is Thank You Jerry so you can actually so this leads into the next point you can actually use the tooling we've released if you go to github.com slash he was um write contracts in languages like C C++ rust compile them to watch them and deploy them and test them on our test net today and if you're a forward-thinking project and you want to be building for youth to that'd be a good thing to begin testing because he was him is very likely to be the execution engine for a theorem to high-level goals of the project making pig compiles great again because as you probably notice we haven't added any pre compiles in quite a while we want to be able to do more advanced cryptography elliptic curve math that kind of stuff and he wasn't makes that a lot easier it allows you to write smart contracts and a whole host of languages like rust which is really exciting thank you we have a bunch of open questions about the project so here's a few of them interpreters are easier and safer and we have them running so the test net today is running the I think it's only running death is that correct right with with a wasum interpreter called wagon however the whole point of e was him if we want to deliver better performance we need it to be compiled whether it's ahead of time or just-in-time compilation but that raises questions about about pieces of code that may cause compilation to take a long time we call these JIT bombs right and we haven't solved that problem yet so there's an open question do we need to write our own compiler is there an existing compiler that works how do we do gas metering we have again each of these is a deep topic how do we get you azzam on to the main net so one option is as I said before we deploy this maybe as part of the eath 1x roadmap as a sort of final precompile or one precompile to end all pre compiles which is to say that anyone could then deploy user contracts instead of needing to add more pre compiles we could replace existing pre compiles with awesome base pre compiles we could we could meter native code pre compiles using wasum we have a whole host of reasons which Alex walked through in great detail in our session this afternoon so look for his talk if you want way more detail on that he was M is on the roadmap both for eath one X as well as e 2 and so we have some questions in our team about our own priorities and and can we do both in parallel and and do we want the same approach or different approaches which languages do we want to support so we're looking at things like rust and C C++ and maybe this cool thing that looks like typescript called assembly scripts so love to hear from you guys about which languages are most exciting I think that's oh boy okay yeah limited time if these are interesting if you have questions if you want to dig into these we'll do that in a sec I think this is my last slide honey wasn't yeah or says we need to prepare a similar hard fork timeline to what he showed you Alexei is state fees plan I agree that would be great let's work on that we have some we need to solve some of those questions before we do that right now we're doing a lot of amazing work on benchmarking right understanding the different performance characteristics of the interpreted wasum versus the compiled wasum of wasum versus EVM of different compilers and different interpreters Jared gave a really great presentation also this afternoon which you can also look for based on a lot of work done by Casey and a couple of other members of our team on benchmarking to understand what our goal should be so yeah we need to figure out how to get this into eath 1x we need to write some VIPs that's on the table you know I don't know I I pulled these numbers out of thin air so feel free to disagree but we need to yeah so hopefully hopefully right we'll hit targets of kind of roughly q3 this year being ready to launch first he wasn't into production on youth 1x and of course in parallel I'll be through stuff is happening as well or Corrections or additions so I'm not amazing with compilers what are the constraints on what languages can be made available to compile down to e wasum like why some languages not others like is it is it just more work is that some are something which is not appropriate like I mean I'm just curious how that works anything with a with the that plugs into LLVM any language with an l vm front end can be compiled to awesome and I would add probably so the broader answer is tooling right what tooling is available when so some languages I think we've had experiences with like rust for example or assembly script is a good example actually assembly script compiles down to really lean wasum which is great I think rust by default compiles down to very large while some binaries and so you need to do certain pragma things to like remove standard libraries things like that it's mostly a question of tooling um as a def developer like and i want to build something in e wasum am i gonna have availability to like every LLVM language to write contracts in I think the short answer is yes but the slightly longer answer is someone needs to write the tooling for each of those so we have a quasi official set of supported languages which I think at this moment is C C++ which Paul's done a lot of work on and rust which Alex and Jake and I don't a couple of other people maybe have done a lot of work on I've done a little bit of work on assembly script which I'm excited about so pick your favorite language and help us write interpreters and compilers and tooling basically awesome so it if I understand then then I can write kind of like you know very like rudimentary C++ contracts right now using you awesome yes Jake do you want to talk about writing us some contracts in C++ correct grab that Mike is that okay the answer is yes you can talk to Jake Oh straight straight Thanks community I have sort of a noob question just about performance so so how much better is that you wasn't performance compared to current EVM performance Jerry I just did a presentation on this do you want to talk about it for a second so for how to put this so for it it isn't as good Washington native performance isn't as good as say like for example I think CloudFlare death uses cloud flares implementation of easy pairing which is like handwritten assembly so it's not as good as stuff like that it's not quite as good as the native code or the native pre-compile implementations at the moment so but it's it's within the four most pre compiles it's within the range of I would say 11.5 to two times as slow which sounds really bad but just remember that I would say it's not at least some it's not a it's it's not about performance mostly it's about well I know I know that's a terrible statement at face value right but if we can get the performance close to good enough as the current pre compiles and we it's more about being able to put the put more cryptography on chain without increasing burden on the testing team I second that performance is not the main goal of the he wasn't project it's it's exactly what Jared just said we want to make it easier to do stuff like complex cryptography that chain basically and just to like I'll pass this unisex Jamie but just to explain my last statement I think it puts the and the reason why it takes the burden off of the testing team or some of the burden off of the testing team is it takes the so currently the implementation the different implementations all have to be correct and they all have to have test cases to describe all the edge cases of the behavior whereas where we move a level lower and assume that the Wazza mentions and this the this that are implemented according to the spec and that we are kind of dipping into this wider ecosystem to ensure correctness okay let's move on have one question um so my question is waz him for one X is the proposals just for pre compiles it's not for dabs am I getting that correct lane so the question is was um for one X is just for pre compiles not for daps okay what am I talking about I mean ideally what we would want is to have everything and the proposal is the multiple variables in the system right so one variable is the interface is exposed to two awesome and the number of interfaces exposed so you have like a contract DVM itself exposes were like between 20 and 30 individual features to the state and you want to have the same number of features exposed to awesome if you're writing a contract now that number goes down significantly to reflect four or five items if you only do pre comp eyes and you can add a lot of like features on that level on the other side you also have the risk and complexity of you know any any code which might trigger issues in compilers or may not fare well with interpreters so judging like these two factors is is the reason we have been looking a lot into considering pre comp eyes for it when X and at the benchmarks kind of show that's kind of like going back to the previous question on benchmarks and I think the real question to ask may not be how does it compare against current pecan pies but also how does it compare against EVM and we have done benchmarks between even a VM implementation hand optimized EVM implementation of the same code like hashing algorithms versus having it not hand optimized in wasum and and we got depending on the algorithm itself like between 5 and 30 X speed advantage to the wasn't version and now what Jared was saying compared to like a really performant hand optimized pre-comp eyes for crypto in that case like there was an interpreted wasn't doesn't really fare that well it's lower so what I'm getting at is we have like two different targets we can look at pre-comp eyes which go with interpreters and if you can go look at pecan pies which go well as being compiled and we're trying to address like both cases and recent process of having like good guidelines you know which one we suggest or it's ultimately not only us deciding it what we want to do is like getting all this data right writing all these different proposals so these are the pros and cons for each of these and the divider ecosystem has to decide awesome thank you so starting at Berlin last year a group of people started working on kind of a label called EVM evolution so improve the EVM support the II wasn't team with forward compatibility again what changes can we make what is it going to look like in the transition that's been a large chunk of it has been Greg my co-founder Brooklyn and myself we've got an outstanding application for an EF grant Greg and Brook who are co-authors have proposed EEP six one five four the assemble hard fork this helps a lot with security and static analysis so we've had a lot of support from the trail of bits team consensus diligence and the security community who are excited about this and other people who are fans of formal verification and static analysis so certain classes of things are improved here as part of this as well has been an increased focus on improving and maintaining the EVM specification with the jello paper and formal verification so as an example we don't yet have the Constantinople eeap's formally specified that's another proposal that I'm going to suggest whoops sorry as part of this next hard fork that we get those specifications done before the hard fork act active eights I have contacted Alexi to see if these dates work for him as he's a major lead with state fees I'm announcing this now and I'm just working on planning from a quartet meeting in Berlin I believe that we need to set aside time that isn't ad-hoc at conferences much like the January Stanford meeting to have planning to improvements of the network as dedicated and priority time rather than fitting it fitted getting around conference travel we've got a bunch of other questions around funding testing security reviews if we want to improve the process to add more security reviews or security audits how does that scheduled and how does it get funded are the people who create the eeap's responsible for it open discussion we're very close to the end of our time four minutes other questions comments could you list out the benefits of evm evolution just to the to DAP developers so it's more of a matter of right now there's people building gaps building smart contracts on the network today II was um full support for gaps let's just say it's gonna be a while I don't think we're gonna have DAP support in this next assemble fork Alex smart contracts written for Azam by it's unlikely that we're gonna have that therefore let's continue improving the EVM for security and performance again with the understanding that it keeps going you can also use the LLVM with the EVM so we can support lots of other languages if we want to and we've been talking to Microsoft research and Intel and many others who in fact use the EVM and are very excited about the EVM if we were starting today from scratch wasman would be the likely choice actually the other thing to mention about was him that just came out from the last couple of days so several people have been independently reaching out to the essentially upstream wasum the group that's that's creating the specification that everybody uses for wasum and they're very interested in having the etherium community participate so part of that is working on those upstream specifications as well so all of this work is going on in parallel and needs to be done so we need to keep improving the EVM we can see real gains today while making sure that all these things get pulled into he was and research and which applies to both Eve 1 and Eve too um I just wanted to say about - I wanted to dispel a myth that I've been hearing a lot lately it's not around the corner it's gonna be a while we're hoping that there's going to be a beacon chain like late this year or maybe early next year but we still don't even really understand how far it's going to be on the roadmap that's step zero of the three phases so yeah the need for eath 1x is very real and I think it plays into both should we end it there I think one of these things is a call to action really at the end of the day there's been lots of back and forth on this let it be clear everything that we do right now the growing open financial defy dope Phi ecosystem all of it is running on the chain that we have today we need to keep working on it we need to keep funding it we need to keep making it secure that's why we're all here so encourage people to get involved to watch the e process to hold various players in the ecosystem accountable for stepping up and making sure that all this succeeds with necessary resources I look forward to seeing you in the ethereal magicians forum and elsewhere in excellent open source code see you on Shane [Applause]