# Eth2.0 Client Panel (Devcon5)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-09
- Duration: 35:59
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-XJRmdiK-eto
- YouTube: https://www.youtube.com/watch?v=XJRmdiK-eto

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/5/eth20-client-panel

Panel discussing the short-term future for Eth 2.0 clients. 

Speaker(s): Various
Skill level: Advanced
Track: Consensus layer
Keywords: eth2, technical

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

welcome everyone to the a theorem 2.0 client panel discussion the idea what this is - well after this morning's presentations where we saw lots of the work that's been done and and been given insight into - some of the solutions that have come up with to explore more how we move on from here in particularly how do we do that together there's a lot of - togetherness I think in general in a theorem 2.0 there's there's many of the the the design aspects have been centered around trying to coordinate people be that through the use of technologies that other people are using was on the p2p BLS standardization etc to the multi client approach we're taking and I think it's a really powerful a powerful thing as we've we've we've seen and so I think a good place to start off with was something we had quite recently which was the Interop event this this look great a great opportunity where we looked well some he basically locked a bunch of people in a room to see what happened and and the results of this experiment was we got seven clients speaking to each other which is pretty pretty freakin incredible and yeah so so so now that we've achieved that I think that's that that's allowed us to do to get a lot further along this this route so I think you should have some introductions before we quickly dive into this so if you can start down that side and have everyone just say the name what who they're working on and what was the sort of one thing that they took from from from Interop or what's the the one maybe the the main thing that you guys are now working on as a result of Interop hey I'm Ben I'm just standing in for the great Joe DeLong on this panel I kind of assembled the Artemis team a year ago I'm best better known for what's new in eath to these days I was at Interop and it was awesome takeaways I think it's time to press on to production now we've proved the concept it works we can interoperate it's it's very cool but now we're moving into a new phase with without a Miss and handing it over to the production team to do all the stuff like writing documentation and and searching the comments for to do and all that all that good stuff everyone I'm rolled from prismatic labs I was unfortunately not to interrupt but uh remotely helping out the teams there and figuring out kind of how to get people on board prism one of the biggest takeaways was getting everyone to easily run a beacon chain and a validator mate like we had to make it easy for everyone and it improved a lot of our local development a lot I made it very very easy to launch a beacon chain with n number of deterministic validators so that's sort of standardization that came out of the effort made our lives easier and hopefully others lives easier everyone I'm Alex Stokes I work on Trinity which is the python implementation of eath - oh yeah Interop was great as well probably I'll tell you here the biggest thing I think we probably all saw across the board was yeah just having like these sort of coordinated starts and like getting these tests nets to actually like all go at the same time we have a large number of clients and so we have some extra fun just like wrangling all these cats there's like a bunch of little stuff that we saw sort of specific to Trinity from the Interop and the big thing that we'll probably be focusing on longer term over like the next I don't know let's say three six months is a heavy focus on performance like I said we're a Python client so we kind of have a performance penalty we incur de facto so we'll be doing a lot of a lot optimization there we were looking at dropping our like really sort of tight loops and things interests so we've had some work on like rest modules and Python which is fun and yeah that's about it hello everyone my name is Paul I work on lighthouse it's one of the rust implementations I think one of the great things that came from Interop was just a lot of scripts that we can use to build each other so Yessica built a bunch of scripts which was great so now we have we have a bunch of tools that we can use by ourselves to test with other clients so that really helps reduce the friction that we can before we can test our client against others what we're working on now after Interop we're basically targeting feature completeness we have an RFP for security review out there so we're preparing for that and we're working on trying to take a client into the sort of the tens of thousands of validator ranges and above to make sure that we can run nice and quickly and efficiently with production level numbers of validated I'm sorry from the Nimbus team lesson that we learned from Interop I guess is the importance of testing our success was largely due to the very well-prepared a suit and where there was bumps along the road this is places where the tests are kind of missing I would repeat what what Paul said that one of the most valuable takeaways was these scripts that allow us now to run multi client s nets and now I think we should all keep improving on them and regarding the future of Nimbus plant will be planning we'll be publishing very shortly our roadmap for getting Nimbus production ready and we hope to do that in the next six months hi I'm Desmond from wrong time verification so we developed a kind of client but we are not really just running the client but formally verifying the client so but I hope there's some crazy idea of crazy users use our K client as just adding another diversity and yeah but yeah so far we just for verification first though my name is Mikhail I'm from harmony team and the Interop went very well and I even didn't expect it it was so productive as a follow ups we are continuing to work on EV fork choice tests like a complex test also we need to finish sync and was thinking about start working on Bella stuff finished in discovery and the main takeaway from interrupts that we are merging efforts with Artemis so we probably can avoid this production really stuff so yeah ok that's it I'm away from party so I think I I didn't join the interval on site but I was doing some similar interrupts stuff at home trying to get it work put them all nice it mostly works I think the most important lessons we learn is to testing so we were while or to patched version behind but even even except that we still have like power to consciousness bugs from drawing the interrupts that doesn't pick up the test doesn't pick up by the tests we pass all the tests before so I think that's the biggest lesson we learned testing is really important also I forgot to say that we tested GBM the p2p as well as our client and he fixed some bugs and it's now compatible at least the stag that used for Interop is now compatible with all other implementation like JavaScript Python and rust and you I also just wanted to use this moment to toss out a PSA we're all using the same BLS library at the moment I believe yeah so if anyone out there wants to write it'd be a lot of implementation more implementations is better on the note of bilis implementations the standardization efforts have been charging forward and we have some more reference implementations from those efforts so hopefully within the next 1 month or so we should have what is the final specification for pls and which is really a major step forward and means that basically then that's the me the last hurdle in terms of specification that's left you know so moving on and we've had all these these interoperate events but we need to now start transitioning to more organic starting up of these events and and allowing nodes clients to properly sync with one another with with we previously used scripts and files to start up these these test Nets but to have more we allow validators to join into your network and transitioning into proper test nets so I would be interested to hear comments on what how we can do this and sort of what are the challenges and what are the next steps in these regards yeah so I think a huge step forward from what we had at Interop would be sort of testing out our eighth one integration I think most of clients have at least some form of it but essentially this would be like having you know some eath one test nut ideally one that we kind of all could easily for example produce eath for or spin up or spin down as we need and then use that to kind of test ok like you're saying here's a real world setting where it's like there's no eath one network we then have this if to deployment how can we actually have validators join and leave but mainly join [Music] yeah I think it's time for specialization I think we're gonna see like all the clients at this point now that we know we can talk and we know like we have a baseline we're gonna see everybody kind of splitting down isolating and like going down basically challenging you know their languages and their respective implementations to whatever it is that like their original goal was set out to be I think that's probably will see like half in the next six months for us as well then the very next milestone is running test nets connected to each one and for this so we've been following the lead of prism and we've been publishing deposit contract on the Gourley Network and I expect that we have some interoperability with they'll be able to use ours contract and you'll be using able to use theirs and so on and there have been some talks in here with the past few days one of the clients agree that it would be beneficial if we set up a shared organization on github where everybody has commit rights and where we can work on and improve these scripts that allow each developer to bounce test nets on their own computer on their own environment so I see two directions one is public facing test nets running on each one and then the ability for everyone to just make quick walka setups yeah I mean that we really enjoy using early I think corley is becoming a lot more of a de-facto standard as well for like each one devs to test out smart contracts and it's been really nice to try out deposits another big effort is the ARP is like the API standardization effort that will come over the coming months so there's a lot of talk about not having people use the CLI to stake to run validators you know can we have a standardized API that allows people to build things interesting things like while it explores other things that allow you to interact with the chain and that will be a really critical effort over the coming months as well so on the note of sharing deposit contracts do you think it's worth then having one centralized deposit contract or earlier so similar for what of this night last night this makes a lot of sense to restart them frequent frequently and then nothing prevents you from having multiple deposit contracts being active at the same time you know basically the client only needs to specify the address of the deposit contract that he'll be using just in terms of the the shared deposit contract I think something that would be nice too would be a common onboarding process for validators I think TF was maybe considering about jumping on that so yeah it would be nice if we don't all have to build you know a million different little validator onboarding things than to be superseded by an official one coming out we also probably want to test this beacon chain start for many times because it could be a huge point of failure I mean the kicking off from eath one chain to the beacon chain so it's probably worth to focus on as well definitely we don't find that often in production and on that topic I think it'll also be worth discussing what are the what a valid criteria how would we decide that we are ready to do this main net launch so I agree one of them should be that we've had launchers bastes based off f1 and these starts but how do we actually decide that this is the finalized version both in terms of we can specify minimum each deposits and that kind of thing but also more in terms of how what we require of clients to be able to participate in these networks and and how do we say that this client should should or shouldn't participate I mean obviously it's not gonna be some definitive thing but what what is a good signal for deciding that a client is ready for participating in in am a net launch I mean yeah that's obviously a big question at a high level right like I would expect we want this to be actually fairly community driven probably like highly directed by the client developers themselves obviously there's things like uptime and performance and stuff right so for example if we end up with like a ton of early validators we all want clients to be able to handle that many validators I know for example Trinity like can't scale to like the theoretical max right now like we just don't have the performance we'll get there but we're not there yet so these types of things are like it really important qualifications you know at a certain point it's hard to say like are you ready you can always defer and like do more testing so a certain point you just have to like you know I'll say well these are all sounding really negative I was gonna say jump off the cliff or something but yeah hopefully we know it when we see it and we're like okay we all feel good here we go yeah I agree the story that there should be some we should start testing with some the parameters that affect the performance of the network we should start validating that each of the clans is ready for this but our own roadmap is also built around the need for security for performing security audit on our code and this is a pretty complicated thing to plan out because it requires you to freeze a lot of the code so we are currently creating a plan that will allow us to create sort of a pipeline for smaller and smaller components that will go through audit and then bigger and bigger parts until we are ready to answer yeah as country comment along the same lines I mean in this network you can't prevent anyone from saying I'm a validator and being part of a network Ronit that's the whole point so it requires client teams need to take responsibility on the one hand and so I think exactly right audits are going to be important one of the very strong differences between aetherium two and a theorem one is that in eighth - we need to do online signing you have to have your key available to sign in real time which is something that all the f1 clients and nodes have moved away from over the years because it is really hard to do it securely so that's going to be a critical point where we need to focus audit and security effort on that and on the other hand users need to be kind of wise as well because they have to choose a client in which to to run and to stake and so forth and I think the best thing we can do there is probably to have some joint benchmark suite or you know some make is all about information right and making it consistent and so people can compare and contrast and you know understand which is the client that meets their needs but yeah I definitely like to see a diversity I think it would be a shame if the network were dominated by one client more than 50% on one client would be would be a pity I guess another point of point of importance is formally verified the safety and live needs of the beacon chain so amazed you know that I mean in the paper was the paper that proved these two properties on that the abstract model of the beacon chain but reality is the implementation has caught a lot of the optimization and also it's slightly different the finalization rules so you also make sure that those differences doesn't actually break the safety and avenues so yeah that's our actually calling in our end you wanted to finish the phone verification before others are actually ready to release and the the safety of all our clients relies on this assumption that someone's gonna slash bad people I don't know anyone that's got a slash of working that can that can efficiently run they can efficiently cover the the distance that we need and it's still in research as to you know how exactly can we how can we store all of the previous votes and efficiently search them so we're really we're definitely going to need Slash's out there and I think they're gonna have to have some degree of review and guarantee that you know they're watching and they'll get you adding on to that quickly you also need like slashing protection right so like in terms of like infrastructure providers or people that are they just don't want some sort of crazy situation with their infra to cause them to double propose or double sign so that's also something needs to be built in and users will be asking for that I totally agree with everything that Ben said and one just yet that we might probably need some more QA stuff like fuzzing we want to do cross client fuzzing to find tricky consensus breaks that could not be probably fine it could not be probably found during test net runs and also we need to expose basic interface to chain data to build even primitive block explorers around that and to get some network monitors to understand what is going on so yeah that's that's my point another fun thing leading up to production would be incentive ice test nuts so in a cosmic community they've done some of this with the game mistakes it'd be fun if we do the same thing get together prize pool and the idea is we have a test net public test net anyone can come and go and then try to keep the test no life other than everything would be like actually talking to validators or potential validators and like getting their input sort of been like a product feedback typesetting I think we were all very focused on like the spec and like the engineering and like making really nice sexy clients but definitely it's like for physio who are the users of these things well validators so talking to operators of validating that validation pools and not actually just pools but validators in general and yeah seen seen how that process unfolds sorry one more I think we need some interest from external I get guys know inclined developer team you eye people so I think a lot of the client developers where systems programmers and the idea of choosing a color makes a sweat so it would be great to have and we don't we don't I think at the moment have maybe a few of people that are like you know front-end devs that are that are interested in building UIs for this and it'd be great to have these things as a common good that lives outside of the client teams that gets to love that they deserve and on top of that I think it's very important for the the general validating experiences to to not only just help them with the general running of the clients but what happens when validators get slashed how do we notify them of this or when there's this major chain consensus how do you if your clients not updating or there's something did this there's some fundamental issue how do we notify clients like of these problems and I mean we could trouble you have some central solution which sends you an email or something but having people register they validators with such a thing as a kind of scary concept from a privacy standpoint so how can we how can we enable these kinds of things which I think also very important for the for the community and and to help validators understand a what their clients doing and how they can stay on to all the things cool well with that I think cuz we were heading into the final minutes yeah I'd like to open the floor to questions for anyone who'd like to talk about anything related to immediate future v3 Pune I'm somewhat forwarding this question from Philip casting guy from horizon games and the fairway and Ponzi scheme revelation my name is John Marlon I do security audits so I'm not adaptive but I know a lot about smart contracts and his question is about like the migration process and if there will be if there are plans for doing any migration testing for gaps moving to the youth to maintenance test night yeah no definitely so the the migration from f1 to teeth et tu is clearly something that came up in the discussions yesterday too and and is a very important thing and clearly a pain point for the community I think that's something everyone is nervous about we have this great community within varium one how can we we transfer that as seamlessly as possible we don't want bugs in any of these scenarios the the verbs the challenge with answering this question is that right now we have such flexibility in the space that is very hard to answer exactly what this is going to look like so it is some form of moving routes between earth 1 and E 2 and we will have an execution engine which allows each one to run very similarly to how it does right now and that will be very well tested for for these kinds of purposes but I think the the the challenge here is we're trying with with these execution environments that allow us such flexibilities and so many possibilities we trying to not lock ourselves down just to to committing to saying exactly this is how it's gonna work right now because that starts closing down the the design space for us and and it could ultimately end up in a worse product so the the answer to that is yes it will be tested there will be some migration path exactly what that looks like I can't specify right now but we did that will definitely existent is vital for for the continuation of a theorem 2.0 and just add on to that like concretely there's definitely an intention to essentially move eath one into the new eath 2 infrastructure in a way that you wouldn't have to migrate your adapt and it would just continue to run not quite seamlessly there'll be some sort of metadata updates of like Oh new network new chain that sort of thing but in terms of like you would enough like rewrite your DAP or like do these things that being said there will be an opt-in upgrade path to go to perhaps this new type of EVM ee that karl was alluding to which you get like a lot of honestly like great improvements on top of what we have today so yeah keep an eye out and I think a lot of this ties into what Griggs presentation was on earlier on Harvey making connections and building common tooling between these these frameworks and it's very important to have these intermediate tools between the two chains it's totally having a easy path for upgrades is definitely important and it'll be there something else worth considering too is that you know if you if if you've just gone from like this pocket calculated to this like multi-core like thousand times faster machine that perhaps a refactor is is is gonna be important for a lot of the taps like we're not not saying that like you're gonna have to refactor but you got a lot to do it like you got a whole new space to play and now so it might might bring a refactor might be what you end up choose doing because it will be better for your customers or not customers people that are using your thing opting in without any control from you where's this conversation happening where do you guys like you know interact with the DAP dev community so they can ask those questions it's hey I can speak on behalf of that a little bit like we're a little bit early still you know that's like phase two and to be quite frank like the role a lot of confusion around this is because like some of the as Carl explains it like the design space is so open but it makes it also super complicated like a lot of people I feel like rethink the way this is I mean how long did it take most developers to actually understand the EVM like two years like before people like fully understood so it's gonna take some time to understand these new concepts and once that happens you'll see a lot better I don't think it's immediate to fully discuss with them I think the first priority is just talking with like tooling teams to understand that we can better help them and concurrently going with adapt developers yeah the quilt team deserves a plug here - they're building a simulator so that you can build II's or tests on top of e's without needing all the chain infrastructure you can just start a process and start start testing so I think this is something that's gonna really enabled app developers developers to get involved because it's a bit a bit low level at the moment I think for them but it's opening up to them so we were at interrupts to lose my blog and we're very grateful I think we was fun to work with out of you we did a couple changes so that's also an announcement for change safe in particular so we support alpine so we don't be to mess around if you alpine for docker images so it would be pretty easy for us to set up a test it was your stuff I think we just do you have a docker image okay cool and Wade you have a docker image as well okay all right so if we can help in any way we're here to help right yeah just give you this like credits and fonts with that so please involve us and we'll be happy to a couple you you know probably know like some of the eath one core core devs but usually a lot of them are kind of like detached so it's like if if there were some things with eath to designs that you would want them to like try to look at like maybe each of you it's like what what is it that you would really like them to look at because there's a lot of brainpower there as well thanks sing strategies [Music] we're running out of time so can we use this as like sort of a wrapping up thing as what yeah data serialization API standardization efforts okay this is not just a single line still working on Trinity we actually have a focus of both eath one any two so I actually feel like I've been exposed a lot to a lot of the eath one efforts and ongoing two things and like really from what I've seen like both groups of quote weirdos are like starting to really just tackle the same questions I could pick one that comes to mind is like state management and things we obviously want to like you know we've seen what has happened on 8th one in terms of the state growing and growing and growing and we want to you know basically find a solution 8th - we're like that's not going to be a problem and yeah like the law there's lot of cool ideas are like state those clients and things that again have application in both domains might be I think a good thing we can learn is what to and not do with in terms of governance what we have right now with anything point to is if they're 2.0 is the research team I think leads a lot of the decisions and so there's sort of a central shelling point which exists much less than a theorem 1.0 and the idea is that the the research team wants to have less and less of this role but how can we do this in a manner that prevents deadlock and allows for continuous innovation I think a lot of lessons to be learned from F 1.0 that I'd be willing to take anything I'll take any advice from any of the people that have building been building as one or Bach chains or people like anything they've got bringing here came for it I think there's a lot of who we can learn about right clans how to create light trance from it one and on the other hand ATM one will greatly benefit from the fact that the e to chain will be finalizing it one as well so it would be much easier to create efficient light clans for it one but the instant evasion schemes the dog balancing of the requests this these are areas where we can share the solutions and and on that grant I'm kind of excited about the possibility of each one incorporating the p2p support in some way this is some something that's possible in the future okay probably yeah I'd like to take advises with Network reputation systems connection managers and sync strategy and optimized incremental storage for this state yeah that's it I'm actually mostly like related to both Israelis who I'm actually both curved like a lot of parts of pike were a couple really issue like the thing is for like currently if like probably all of you know the unis when we have a breaking change that creates a lot of conflicts I hope we can try to avoid the same situation I mean stew by designing the execution engine biter like make it forward cut Cabello from the beginning I think that's something quite important it's also really important to consider future changes of webassembly because there will be a pwease a diversion is that's how the web works that will be how webassembly specification works so how do we incorporate those new features adopted in web assembly into our my person reacts a fusion engine as to I think that's also something that's quite important to consider just quickly before Carl wraps this up I just wanted to just to announce that we're looking for a senior US developer if you are rust developer and you wanna work enough to come talk to us thank you well thanks everyone for attending that thank you to all of the clients represented here and I'm really like excited to see the DVP work that's gonna happen these these incentivize test nets this may net launch which is like this is this incredible event and then this time next year I look forward to seeing all of you back here on stage hopefully we can talk about these experiences we've had all in good light and yeah I hope there are things very exciting to see where this is going thank you [Applause] you