[Panel] Ethereum 2.0: next step to Serenity | CrossLink Taipei 2019

brother so hello everyone good afternoon Hey so Lisa shall we and undermine her today and today we will happen is to had no discussion so we will talk about history the future and our experience with this is to experts so okay so maybe introduce who you what Union and what's the organization you're working on and what how do we are ppz with recently okay I start again my name is Adrian I I'm a co-founder of Sigma prime which is a company that is among other things it's a it's a security based company but among among other things its building an etherium to client in rust called lighthouse I'm one of its developers i'm Vitalik I'm the developer for Bitcoin tools co-founder of Bitcoin magazine and I'm you know recently a video xmo Theory I'm stuff I am Danny I work on things with these people theory we were gonna on the room to research specification and client coordination in development everyone I'm Alex focused on e to right now the treaty client which is in Python which I'm sure we'll get into why that's a ton of fun I from I'm dyrdek so I maintained a go specification we try to make the spec executable so we can provide this test tooling infrastructure for these different clients yeah thanks everyone for joining hello and so we know that is - it contains so many new features we will have proof of stake we will have scalability with charting and what what else the core value that you feel you won't highlight for the audience core values of etherium - in my opinion one of the core principles is bethere into is it an upgrade it's a upgrade ability we're choosing some of the latest tooling some of the latest protocol some of the latest core technologies a lot of its currently being developed actively being developed and we're trying to build it into a new block team so which is why we can't build it on a theory and one that's why it's a new chain because we're replacing everything yeah I'd say the core value is we've learned a lot since the theorem launched and it's time to take all those learnings and make a better more upgraded system but at the same time to recognize and celebrate the community of developers and users that have built around aetherium and to ensure that we do our best to kind of capture that community and move forward into a theorem - and make that process as easy as possible people even like in the word seamless in terms of seamless ether 1d to transition there's a lot of conversation last week at Def Con and probably over this weekend about that type of stuff so personally I think it's really good that's affirm to does not opinion it's the core layer so much and at the community convert build these other great things in the forms of like IES and our tooling closer to the core layer so if there's a lot of things that can emerge only firm to a very not possible um if your mom yeah so I guess going back a bit of the original values of ethereum one yes first of all know we love decentralized applications and open platforms and all of the wonderful things that you can build on top of that and the goal of etherium all along has been to create a general purpose platform where people can essentially like just feel free to go and build things and where you know you can build decentralized applications whether it's finance or some way or some identity thing or or like whatever you wants to build and that you can just like write a piece of code and upload it and you don't really have to like think about who is going to ronique your consensus or how are you going to talk to these other other applications or like I can't store any but there's other details because the etherium platform and if takes takes care of all of the comment stuff for you and I see a theory m2 as and of being a logical extension of that vision and trying to preserve it as much as possible but at the same time deliver a head of massive upgrades and scalability and efficiency improve security through the proof of stake and improve like make the platform even more general-purpose with things like execution environments and again and accounts abstraction and just generally and if as Danny said take all the things we've learned from the last few years and like make the best what form that we can and yes so before we move forward to the east to let's move back I think we call the history so the reason why I think it's too difficult is that we have to fight with the backward compatibility then other new blood trends and there is a DP crate duplicated shouting contract and also that if you created a cancer contract the one the IV 101 one so could you introduce why this change happened and what's the difference between the old Kasper and the new Kasper and at the current be concerned Kasper well I remember that contract I think I wrote it okay yeah in VIPRE yeah I guess base the the big change that we did and about a one and a half years ago is that we decided that instead of building if - as this kind of layer - that's rooted in the existing eath one chain and then in parallel trying to upgrade heath one to casper we would create a new system and the benefits of the new system is basically that we would be able to and if do all optimize it for the specific challenges and use cases of sharding much more easily so we would not have to worry about like oh can we verify BLS twelve 3d1 inside of an EVM or like what's the gas cost of updating state like we can kinda feel free to and if design data structures and a lot of other things in ways that make it unique eats too much more efficient and also just like instead of having this one kind of train of work that is doing if to honor that is doing Casper and this other kind of separate train of work that is doing sharding and kind of eventually hope to merge them we and if bill in your system from the beginning and then and if only get to the existing system and so the new system can run by itself for a bit and then eventually and have moved more and more activity to it over time yeah I'm one of the one of the other reasons that it was made a lot of sense to switch was that the two paths that we were taking that had a lot of execution happening within the EBM we're gonna ultimately limit the amount of consensus participants the amount of validators that could participate in the system and thus you had like high capital lock-up cost per validator participate we were worried about just ultimately the decentralization of such a system taking this more radical approach by architecting the system in parallel has allowed us to greatly lower the minimum requirements to participate to on the order of 30 to eat and so I think we can have a lot more participants and a lot more decentralization from that thank you and so let's talk about be continued so the beacon churn development it's a huge project right now it includes like I think eight active clients including lighthouse address and also Alex and I are working on the Trinity pison client so um for that common misconception you think I think part of it may be just understanding the relation of the beacon chain to eath one so like it is a separate chain it's actually done this way so we don't couple the systems you know until we have to it could be the case that there there's only a one way bridge from eighth 1g2 and then if there's something terrible happens on youth 2 we can like correct it there and not have to really worry about the one consensus so it's really just like risk minimization okay I'll just add to that as well that in phase zero there's there's there's no data or execution environments happening in there any of the shots so when we release phase zero on on maintenance tart running contracts and applications yet but soon yes but see sentian okay then so like next year will happen and then this one is coming so I did a classic from Nimbus and I we did a developer survey last month so we figure all that so talak introduced front proof that they have a yesterday but I think not it's only like half of our community they really aware of the face wise only four data does anyone want to elaborate it more about face one yeah and the goal has basically been to all along lunch etherium in to in phases so that we have an opportunity to kind of test each component under I know for real conditions before first for some time before I'm releasing the next one and particularly have asthma the system tested or as much of the system as possible tested for as long as possible when people start bill putting a lot of economic value on top of it and so the three kind of natural separations to have is basically one proof of stake the second sharding just for data and the third being kind of sharding and including data and computation and the reason to make the distinction is because they there are things in Phase two with computation that are there are fees to a specific problem so like once you have phase 1 adding phase 2 I guess not is not a completely trivial so we have to for example and have fully expected spec out the design for how ether moves across shards for like exactly what kind of execution it is for get the other clients what all needs to implement what assembly like what they wants to optimize what assembly a lot of different details and like there's no point I guess in enough delaying release of the entire system until the entire system is ready when you can get parts out earlier and get them running earlier and get people doing a few doing some things with them so for example like when you have phase 1 then the chain won't do computation but the chain will be able to hold a lot of data and so if for example we come up with a way where the 8th one chain can be aware of the ether chain whether it's through like ability and bridge just anyone's talking about yesterday or through a white client then you could have optimistic roll up start using phase 2 and go up to like hundreds of thousands of transactions a second just as a roll up like even before all of the other applications start running so you kind of crank up the complexity over time crank up the utility over time and it's a kind of naturally is safe in progressive approach also also allowed us to parallelize different portions of the development at first when we were researching specking and people were trying to build phase zero all at once it's kind of like we'd be bottle necked like different parts of the process would bottleneck different other parts but now that phase zero is relatively stable Engineering is like very actively working on that at the same time the research team is specifying phase one and at the same time like super active research between the research team wasn't team quilt team and some others are actively researching the things that are going to go into Phase two and the specifications that come so now by like having things very cleanly separated into phases not only for logical like building but for kind of like release we have like a lot of things moving all together which is definitely a benefit cool thank you and so speaking of this um I think we actually have like three different groups out the client things are working on the face 0 implantation and the protocol designer are working on the face 1 refining and also there are the the phase 2 things like world and he was a yellow counter face to ease the execution environments implementation and POCs and people are worried about that so we have the East POCs right now and people are worried about the composer beauty compatibility between East one and his two and they were worried about like can we still use a TRC 20 in the new cistern and how's the translation change that would you like to elaborate it yeah yeah so people at Def Con definitely talking to developers are concerned about composability and a shard system just in general if you have state and applications that exists in certain shards that want to speak and communicate and interact with applications on other shards there's that fundamentally looks different than it does at layer 1 today in aetherium where I can make a call from contract a to contract be within the same transaction have the results affect one or the other and and so generally in a charter system you don't break composability applications can similarly communicate with each other in an asynchronous manner rather than in sync rest manner the problem the problem is that you do have certain things change in the developer experience around certain things like guaranteed atomicity actions and and having things happen within the scope of just a single transaction and so the developer experience around building applications in a shorter system might very well change but if we have sufficient tools in the higher-level languages to deal with in massive complexity you can ultimately compose applications in a very similar way and do similar things that we're seeing on eighth one and and and likely do even more so definitely a concern and definitely something that we want to spend sufficient time in language design and toolings and languages to deal with but not something that were it doesn't break composability as people were saying yeah yeah and so like the main change that you get when you're shard is that like things within the same shard don't work just as they worked before and the communication between shards can still happen and like with the new I faced one proposal it can even happen was in one one slot but communication between shards is asynchronous I mean instead of being synchronous so what that means is that like you can do a thing on shard a and have it have an effect on shard be have one slot later but what you can't do is do a thing on sharda cause it's a how to read something on shard B and then based on the reading from char would be immediately do something else on shard a right after you can implement these kinds of things on top with locking schemes but what you can't do it directly right and so what that means is that like first of all things like er seat one is for example like you need to redesign them a little bit because for example you can't have like one contract on one shard be the the token contract you would basically have to have a your token have some kind of presence on every shard and like that's fine like the the even the duplication of the ko is not a big issue because if you and you just put the code on the beyond the beacon chain as a beacon chain contract the thing that and like if you wants to do these applications that say oh I want to do one thing and then based on that one thing I do another thing based on that thing I do a third thing like there is also this and if yanking mechanism where you take and have individual contracts and you first pull them all into the same shard then you do a synchronous thing and then if you want you can move them out and this is kind of a generalization of locking as it exists in traditional kind of database atomic transaction theory in and you would need to have read this use different design patterns that kind of maximally take advantage of locking so for example the more you can kind of design your application as being a set of different contracts with one contract per unit of activity the better and one of things you work that way right so for example ENS names are independent contracts maker Dow CDP is are independent contract so you would just need more things to have that workflow and then you would be able to have that kind of kind of synchronous like do attend things at the same time ability as you do now so you'd have to think a little harder but it's still there and if you don't want to think harder you can just live on the same chart that's the stuff you want to interact with in coop for collaboration and another thing that worries community is that about the east one two is to transition and and those so how to use is to a stuff analogy a gadget for each one tune okay and I know that alex is working on the working group about this topic and do you like to share some information of it yeah well so hopefully you've gotten the idea that over doing is like quite ambitious right with all of you too so you know as Vitalik and Danny have been saying like their tangible benefits we can get out of phase as it goes so one of these would be using the beacon chain which is this first phase launching soon TM to finalize the eighth one chain so this is the finality gadget a lot of these like more interesting like to a bridge concepts or like data availability sort of applications we want to do anyth one would require the eighth one chain to know about the eighth to state so this is essentially be the way to do it so we've started the very beginnings of working group to look into this stuff shall we mentioned you know we're literally at the point where it's like okay we'll store like an initial feasibility study like does it make sense to do this Danny way to slim is yesterday and his talk but essentially like it's very risky coupling systems so if we could avoid it that's perhaps almost preferable so then the questions like okay how fast can get youth to out how quickly can we change eath one and you kind of have always concerns racing yes and and also Danny took about the East one to East to breathe yesterday which um and also italic it was sick and Danny's conclusion yesterday which is seeking a balanced design and row map in a world of trade off mmm for and say it's the conclusion a good conclusion for the older protocol and from so as you are the number the first developer of Syrian can say that like that okay and profound the white paper is one is to and what is there any remarkable chat off that and the decision that you committee made and that you'd like to share power trade-offs trade-offs may be the Delft work that was a big trade-off I guess in there were lots of trade-offs in aetherium like and one of the kind of complexity versus functionality was a big one so for example so make the etherium chain added a lot of functionality and you know we have the state tree we've added receipts we added different kinds of crotch contract calls at some points we decided that enough was enough and so like Forex there were features that we wanted to do that we ended up like just not doing because there wasn't time one of them for example was like scheduled calling so a Myka can make a judge call now that is guaranteed to execute say 10 blocks or 100 blocks from now and retrospectively I think it was a very good idea that we abandoned that because otherwise we would have realized that there's these like really serious economic challenges and making it work like for example what if for during every block between say block 2001 in 2000 everyone schedules a call for block 2001 and then walk 2001 takes 5 minutes to process right like that's a problem that we did not even realize existed but we just decided even before realizing it that it wouldn't take 2 more too much time for too little value to provide the scheduled calls and I mean thankfully we did not run into this problem so like that's one example of a functionality versus complexity I mean there's obviously kind of performance versus security and that's a trade-off that gets kind of litigated every day by miners us the upvote and downvote the gas limit and like by the community as they and if yeah one read it to tell the miners how to upload and down both the gas women you know and there's a lot of kind of really is a subtle decisions involved yeah I mean one that I mention yesterday was the [Music] going towards this new sharding proposal that has much fewer charts but has like a better user experience and so total capacity of the system versus the UX of using that capacity and so we're kind of constantly having these conversations around all of the trade offs like we're discussing in the new sharding proposal whether it's worth having multiple shard blocks per beacon slot which might enhance the user experience of having intra shard transactions at the cost of some amount of consensus complexity and it's always it's always a balance another one it would be the presence of E's in phase two right so we can kind of hold some elements of the full protocol abstract by just basically not doing them yet this lets us experiment with different alternatives we have more time to like explore these different alternatives and see what makes sense and what doesn't it kind of opens the path down the road for this almost like permissionless exploration right so you could have different ease on top of eath too but then at the same time this is now like really confusing perhaps to like people who haven't heard about it or then it's like I'm clear like well I want each one but scalable what is this e stuff should I write a smart contract write an EE wait there you can change smart contracts okay wait wait so part of that's like managing the complexity there and like how its message to the community at large mm-hmm and constantly incorporating new information into our like view of that complexity okay as we are just exploring the EE landscape and like the implications to developers and the complexity of building them or and processing them things like that I'm kind of constantly wavering on like okay is this a good idea is that idea it's like so I mentioned a little bit in my talk yesterday this ie is an execution environment in eath one we have hard-coded rules about account and state and what a transaction is and the structure of those things whereas in e2 we're exploring this concept of abstracting those things such that they can be specified specified dynamically to the protocol instead of them existing cohdon that looks like essentially deploying some wasum code to the beacon chain that specifies how to interpret sharp block data essentially how to interpret transactions and how to store these things against a state route our 32 byte accumulator it's it ends up you can do the same thing so you can make an EE that does what looks like a theorem but you could also make an EE that looks like Bitcoin or it looks like some things that we haven't thought about and this as I mentioned yesterday is is very appealing one because eath one could be slotted in as a nithi as an EE while we can still experiment with all the new things and fancy things that we want to do anyth too and maybe an e to e and it also essentially future proofs the protocol and that we can define we can create this like very scalable and decentralized layer that isn't necessarily opinionated about what you might do with it and say 20 years so very exciting stuff but also like new stuff that introduces new things that we have to think about in complexities so let's move to the client discussion so [Music] address here and I know that Sigma prime the the lighthouse client you are focused on building a secure client folded community and there's also some father for the crossed kind for testing out cross type because it is like eight seven class here could you introduce the other yeah sure yeah so my company's kind of focused on on cyber security so the client would building has a strong focus in performance and security so in our development cycle we the company consists of a number of security professionals so in our development cycle we we try and integrate security into it one tool that we use which is I've become relatively popular as fuzzing as you mentioned fuzzing is a security analysis tool which given given an arbitrary function that you have that has a number of inputs you you have this tool that just generates a whole heap of random inputs and tries to break the function so typically when you when you developer and you're building some function you you have a set of inputs in mind and so by generating a whole heap of random inputs then you can typically find things that you don't otherwise expect when you when you're building these functions and and find parts where your client client breaks so we've been doing that in lighthouse and and more generally across all the etherium to clients we realize that security is you know quite quite an important topic so in in aetherium one with the shanghai dos attacks that that there can be attack as there kind of can break different individual clients so we don't want to just secure one client we want to try and secure that all of them so in that effort there's a global I guess there's a an open-source contribution where we're trying to build a thing called a differential fuzzer which is a fuzzer that that that plugs in all of the other all the clients at once and tries to experiment with all of these inputs so that if any of the clients give different outputs on some very specific functions we hope to catch any kind of discrepancies and fix those in the client so that it happens we find those before we reach maintenance fundamentally so yeah we're way contributing to that to that collaboration yeah so the common testing suit and also father it's very important for the cross client implementation and also like I know that during the inter up in September that so many consensus failure were found people across the kind when the Chi actually link connect to each other and what's the biggest challenge you think for the kind foundation so far okay two things on that yeah so we we saw result of all of our differential pricing so you know in the client as you were saying in the client interoperability tests everyone had some malformed had there kind of encoding and so when when clients were trying to connect to each other things explode it because you were getting inputs that you weren't otherwise expecting so with light house in particular we we managed to avoid those kinds of issues because we had done this kind of testing and just to answer your second one the the difficulty so far in building a client I would say is that we're using the technology we're using is all fundamentally bleeding edge we're building the latest everything we've changed or change the signature schemes we're using that like the networking we're using live p2p as you saw a talk from Raul earlier which is currently in development there's a whole heap of things going on there we're building the discovery alone is also currently being SPECT out I'm using the client we're using is rust so even the language that we're building the client in is actively being developed so it's hard to kind of keep track of everything as its as it's constantly upgrading we've got to maintain it and even if the language you're doing is it's changing as well it's it's quite difficult task yeah there's an update in rust actually coming in a month that makes us have to rewrite a good chunk of our code which is gonna be interesting at least you have a compiler team though there's another client that they're even writing their own language from basically scratch yeah yeah yeah kudos to status the nimbus team yeah so on client development difficulties yeah interrupt was fun right we all are using the p2p which also is like sort of it's awesome cutting-edge software so we've been working with 400 and the protocol apps teams on like how can we you know kind of make this work for both parties which I think has been really valuable so there's a lot of stuff it the inter up event where Y after the first time clients we're talking to each other and we found a lot of bugs just from that on top of that and particularly I mentioned I work on the Python client right so Python is great it's like nice and readable compared to say rust it's generally much slower so the questions like okay how can we make early perform at Python client and there's a lot of challenges there just to even do that that's beyond implement in spec beyond writing conformance tests and these sorts of things so yeah lots of fun yes I'd like to add hair there's many many kinds and you're talking about first thing like just randomly finding a book it's already difficult enough imagine nothing like eight different implementations each of their own nuances and so a students wave very testing infrastructure is really challenging here and so I hope like moving towards face hero loans we keep this collaboration strong and help each other find books in like these different clients thank you and I have a question for Didrik especially so yeah Didrik is only 21 years old and researcher is his first job after school so you dropped and I wonder that what's your story of value from interest in certain especially isn't 2.0 yes there's many different things to it I can go into like history all these different meetups I attend that are like both first got me into the etherium it just like to maybe summarize it there's like regardless about your background this maybe you should just focus on like what the theorem offers and so what I like so much about this area is well I already mentioned community there's endless heaps of heaps of meetups are around the world you could go to dance learn about different things you have to filter out some shading maybe like there's there I see I see us out there at projects out there there are some good things there like huge Commission's out there and then besides community there's this world of open finance so he creates everything that we'd like to see from our open world games we play you'd have this this power to create your own little economic economy create your own rules create your own systems and then from there it's like really this this permissionless leg alright so think of Delphi leg house you can build anything with this kind of like permissionless box and they can come from everywhere so anywhere already the in the world it is many different developer communities and they all come to boot back all these different things they come together they emerge and it's like the last 3d thing what got me into the etherium is very very building leg the leg house we're building the protocol I mean you can build this new like constructions and then purely also the challenges I'd like to compare it again to crypto puzzles if this captured with like offense online where they pose like this computer science problem you have to communicate with others you have to show creativity and then there's just this really challenging niche problem you can dive into four weeks and really try and take in and then it's really rewarding they get out come with a solution and this really like all comes together to particle development and that's what we're doing here I love it yeah just the the best hires that I think the EF has and the best hires that a lot of the ecosystem has just two highlights in the discussion yesterday and and and kind of how we found proto it is people that show up and do the hard work because they love it and so like finding projects online and finding things that you're really passionate about and again the community is such that like you're recognized like there is there's only so many people in the world that like show up and just build random things in the internet and contribute and so like it's so your ability to like meet people and your ability to like integrate into these these ecosystems and these come these systems it's just massive and I was talking to cha-chang and some other people from the Taipei community and how that's kind of like counter to some of maybe how agent cultures operate and just like show up and just say hello and just like operate and it's like very direct way but just go for it and you know again proto like is one of he's one of the best contributors to ecosystem and he's just a guy that showed up and saw interesting things and started doing them yes and also I think we've met at the East gobo hecka song the first time so yeah join the hex all and a little part of the story where I after this many different meetups a few conferences I moved to Hong Kong as I exchange students and even they are again there's another community more meetups and then there was this conference and I just miss Charlie by like 30 minutes like like we could have been talking about sharing maybe like I don't know like half a year earlier it would have been fun but like none of us if you reach out and contact these people and show your interest you like you're really welcome and you can contribute yeah just to add to that all the I pretty sure all the etherium to client teams are looking for contributors so if you just go into their repository I know that we definitely are so if you like rust or if you like go if you like JavaScript just go find there go find their repositories look at their issues sometimes I have good first issues to help you get started and I'm pretty sure they're all very friendly thank you and I think we are we only have two minutes left so the final question what is the one piece of practical advice for YouTube to give to the developers you think like if they are interesting is to in different ways and what can they look for look for and the second question yes what can we looking forward to so this the top cup of this discussion is the next step to serenity so what can we look forward next generally I'll have a crack at the first one so advice for developers I think is the first question in my opinion if you find something that you're interested in if whether it's just a hard problem or just a particular language just anything that you're passionate in just get dig really deep into that particular thing you don't have to so in in my particular client where we're doing it in rust and we find some of the the best people to work with the people that are really passionate about the rust language they don't know anything about blockchain they don't need to know anything about blockchain but they really really really like rust and that's perfect for us because we're writing things in rust so if you find something you're passionate out just just if it's anywhere in our space just come and reach out even if it's some very very niche part of etherium too so in our client we're doing a whole heap of things which I tried to highlight if you like dhts for example something some let's go back to rile you like the h tease and you want to build a new DHT come and come and talk to us be passionate is my my suggestion I have a quick question how many of you are developers how many of you that are developers have contributed an open-source project okay about half or so I spent a long time as a developer using open source admiring open source but not ever making a contribution and so I will say feel free to start small like theirs so like if there's a little if there's a typo and a readme just go fix it like if there's a tiny little bug on something like some input parameter or something there's like a wrong balance check just go fix it just gonna fix it just do it and you and I found like finally when I finally dip my toes into open source and I started just doing little things like I got obsessed like I couldn't stop and and so not only if you love da cheese go building HD but like if you just like to code and you use open source like just start making little contributions like they build up and they like that's what open source is I definitely did some type of fixing back in the day and next up for a to test nuts and a zero maintenance um one [Music] [Applause] you