 Welcome everyone to the Ethereum 2.0 client panel discussion the idea with this is to well after this morning's presentations where we saw lots of the work that's been done and and been given insight into to some of the solutions that have come up with to explore more how we move on from here in particular how do we do that together there's a lot of togetherness I think in general in Ethereum 2.0 there's there's many of the the design aspects have been centered around trying to coordinate people be that through the use of technologies that other people are using wasm lab P2P BLS standardization etc to the multi-cliented approach we're taking and I think that's a really powerful a powerful thing as we've seen and so I think a good place to to start off with is something we had quite recently which was the the interop event this this is a great a great opportunity where we locked well some 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 a pretty pretty freaking incredible and yeah so so so now that we've achieved that I think that's that that's allowed us to to 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 the one maybe the the the the main thing that you guys are 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 ETH2 these days I was at interop and it was awesome take place 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 new phase with with Artemis and handing it over to the production team to do all the stuff like writing documentation and and and searching the comments for to do and all that all that good stuff everyone I'm roll from prismatic labs I was unfortunately not at interop but 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 made it like we had to make it easy for everyone and it improved a lot of our local development a lot it 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 ETH2O yeah interop was great as we'll 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 test nets to actually like I'll 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 there will probably be focusing on longer term over like the next I don't know let's say three to six months is 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 of optimization there we are looking at dropping our like really sort of tight loops and things and to rest so we've had some work on like Rust 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 to build each other so yes it got 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 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 a security review out there so we're we're preparing for that and we're working on trying to take our 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 validators I'm Zahari from the Nimbus team a lesson that we learned from interop I guess is the importance of testing and our success was largely due to the very well prepared test suit and where there was bumps along the road but this is places where the tests are kind of missing I would repeat what Paul said that one of the most valuable takeaways was these scripts that allow us now to run multi-client test nets and now I think we should all keep improving on them and regarding the future of Nimbus client we will be planning we will 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 Dejun from runtime verification so we develop K kind of client but we are not really just running the client but just formally verifying the clients so but I hope there's some crazy idea or crazy users use our K client as just adding another diversity and yeah but yeah so far we just formal verification purpose hello 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 the fork choice tests like a complex tests also we need to finish sync and was thinking about start working on BLS stuff finishing discovery and the main takeaway from interop that we are merging efforts with Artemis so we probably can avoid this production ready stuff so yeah okay that's it I'm way from party so I think I we didn't join the interop on the site but I was doing some similar interop stuff at home trying to get it work put them all nice it mostly works I think the most important license we learn is still testing so we were one or two patch version behind but even even except that we still have like one or two consensus bugs found during the interop that doesn't pick up the test doesn't pick up by the test we passed 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 GVM the P2P as well as our client and he fixed some bugs and it's now compatible at least the stack that used for interop is now compatible with all other implementation like JavaScript Python and Rust and go I just want 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 a BLS implementation more implementations is better on the note of the BLS implementations the standardization efforts have been charging forward and we have some more reference implementations from though those efforts so hopefully within the next one month or so we should have what is the final specification for BLS which is really a major step forward and means that basically then that's to me the last hurdle in terms of specification that's left yeah so moving on we've had all these interop events but we need to now to start transitioning to more organic starting up of these events and allowing clients to properly sync with one another with we previously used scripts and files to start up these these test nets but to have more the way we allow validators to join into your network and transitioning into proper test nets so I would be interested to hear comments on well what how we can do this and sort of what are the challenges and what are the next steps in in these regards yeah so I think a huge step forward from what we had at interop would be sort of testing out our eth1 integration I think most the clients have at least some form of it but essentially this would be like having you know some eth1 test net ideally one that we kind of all could easily for example produce eth4 or spin up or spin down as we need and then use that to kind of test okay like you're saying here's a real world setting where it's like there's an eth1 network we then have this eth2 deployment how can we actually have validators join and leave but mainly join 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 what we'll see like happen the next six months for us as well then the very next milestone is running test nets connected to eth1 and for this so we've been following the lead of Prism and we have been publishing a deposit contract on the goalie network and I expect that we will have some interoperability with around they'll be able to use ours contract and we'll be using able to use theirs and so on and there have been some talks here for the last few days a lot of the clients agree that it would be beneficial if we set up shared organization on github where everybody has commit rights and where we can work on and improve these scripts that allow each developer to launch test nets on their own computer on their own environment so I see two directions one is public-facing test nets running on eth1 and then the ability for everyone to just make quick local setups for quick validation yeah echoing that we really enjoy using gorely I think gorely is becoming a lot more of a defective standard as well for like eth1 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 a CLI to stake to run validators you know can we have a standardized API that allows people to build things interesting things like wallet explorers 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 on gorely or similar well for all of these net net test nets it makes a lot of sense to restart them frequently and then nothing prevents you from having multiple deposit contracts being acted for the same time you're basically the client only needs to specify the address of the deposit contract that you'll be using just in terms of the shared deposit contract I think something would be nice to it would be a common onboarding process for validators I think the EF was maybe considering about jumping on that so yeah it'd 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 these become change start for many times because it could be a huge point of failure I mean that kicking off from each one chain to the beacon chain so that's probably worth to focus on as well definitely we don't want to find that out in in production and on that topic I think it also be worth discussing what are the what are valid criteria or 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 based based off each one and the 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 how do we say that this client should should or shouldn't participate I mean obviously it's not going to be some definitive thing but what what is a good signal for deciding that a client is ready for participating in in a main net launch I mean yeah it's obviously a big question at a high level rate 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 a 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 when we see it and we're like okay we all feel good and here we go yeah I agree sorry 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 clients 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 would 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 launch yeah I was going to comment along the same line so I mean in this network you can't prevent anyone from saying I'm a validator and being part of the network around that's 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 striking differences between Ethereum 2 and Ethereum 1 is that in ETH2 we need to do online signing you have to have your key available to sign in real time which is something that all the ETH1 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 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 point is formally verify the safety and liveness of the beacon chain so I mean as you know that I mean the in the paper wise the paper that proved these two properties on that the abstract model of the beacon chain but reality is the implementation has quite a lot of the optimization and also it's slightly different the finalization rules so just make sure that those differences doesn't actually break the safety and liveness so yeah that's our actually goal in our end you wanted to finish the form 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 slasher working they can they can efficiently run they can efficiently cover 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 gonna need slashes 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 cost them to double propose or double sign so that's also something I need to be built in and users will be asking for that I totally agree with everything that been said and the one just to add that we might probably need some more qa stuff like fuzzing we want to do cross client fuzzing to find three key consensus breaks that could not be probably fine could not be probably found during the test net runs and also we need to expose a 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 in some device test nets so in a cosmos community they've done some of this with the game of stakes it'd be fun if we do the same thing get together a 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 not alive other thing would be like actually talking to validators or potential validators and like getting there and put sort of in like a product feedback type setting 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 phase zero who are the users of these things well validators so talking to operators of validating the 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 guess non-client developer team UI people so I think a lot of the client developers where systems programmers and the idea of choosing a color makes us sweat so it'd be great to have and we don't we don't I think at the moment have maybe a few people that are like you know front-end devs 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 general validated experiences 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 there's some fundamental issue how do we notify clients like of these problems and I mean we could triply have some central solution which sends you an email or something but having people register their 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 are also very important for the community and and to help validators understand a what their clients doing and how they can stay on top of things cool well with that I think as we're heading into the final minutes here I'd like to open the floor to questions for anyone who'd like to talk about anything related to immediate future v3.0 I'm somewhat forwarding this question from Philippe Castingui from Horizon Games and the fairway and Ponzi scheme revelation my name is John Marlin I do security audits so I'm not adaptive but I know a lot of the 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 dApps moving to the ETH2 mainnet test night yeah no definitely so the the the migration from ETH1 to ETH2 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 Ethereum 1 how can we transfer that as seamlessly as possible we don't want bugs in any of these scenarios the the the 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 ETH1 and ETH2 and we will have an execution engine which allows ETH1 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're trying to not lock ourselves down just to committing to saying exactly this is how it's going to work right now because that starts closing down the design space for us and and could ultimately end up in a worse product so 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 that will definitely exist that is vital for for the continuation of Ethereum 2.0 and just add on to that like concretely there's definitely an intention to essentially move ETH1 into the new ETH2 infrastructure in a way that you wouldn't have to migrate your DAP and it would just continue to run not quite seamlessly there'll be some sort of metadata updates of like a new network new chain that sort of thing but in terms of like you would not 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 EVME that Carl was alluding to which you'd get like a lot of honestly like great improvements on top of all we have today so yeah keep an eye out and I think a lot of this ties into what Greg's presentation was on earlier on how do we making connections and building common tooling between these these frameworks and it's very important to have these intermediate tools between the 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 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 going to be important for a lot of the DAPs like I would not not saying that like you're gonna have to refactor but you got a lot to do like you got a whole new space to play in now so it might be a refactor might be what you end up choose doing because it'll be better for your customers or not customers people that are using your thing opting in without any control from you where where is 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 frankly like the rule a lot of the confusion around this is because like some of the as Karl explains it like the design space is so open but it makes it also super complicated like a lot of people have to like rethink the way this is I mean how long to take most developers to actually understand the EVM like two years like before people like fully understood it 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 how we can better help them and concurrently going with the DAP developers the quilt team deserves a plug here too they're building a simulator so that you can build EEs or test on top of EEs 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 enable DAP 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 hey so we were at interrupt to whose white block and we're very grateful I think we was fun to work with all of you we did a couple changes so that's also an announcement for chainsafe in particular so we support Alpine so we don't need to mess around if you Alpine for Docker images so it would be pretty easy for us to set up a testnet with your stuff I think we just do have a darker image okay cool and wait you have a darker image as well okay all right so if we can help in any way we're here to help right yes give us like credits and funds for that so please involve us we'll be happy to help a couple of you you know probably know like some of the ETH 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 ETH 2 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 brain power there as well thanks sync strategies so we're running out of time so can we use this as like sort of a wrapping up thing as the what yeah data serialization API standardization efforts okay this is not just a single line so working on Trinity we actually have a focus of both ETH one and ETH two so I actually feel like I've been exposed a lot to a lot of the ETH one efforts and ongoings of things and like really from what I've seen like both groups of quote core devs are like starting to really just tackle the same questions like a big 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 ETH one in terms of the state growing and growing and growing and we want to you know basically find a solution to ETH two where like that's not going to be a problem and yeah like a lot of there's a lot of cool ideas around like stateless 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 we what we have right now within a third point two is a third 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 in Ethereum 1.0 and the idea is that 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 there are a lot of lessons to be learned from ETH 1.0 there. I'd be willing to take anything I'll take any advice from any of the people that have been building eth1 or blockchain or people like where anything they've got bring it here keen for it. I think there's a lot of we can learn about light plants how to create light plants from eth1 and on the other hand Ethereum 1.0 will greatly benefit from the fact that the eth2 chain will be finalizing eth1 as well so it would be much easier to create efficient light plants for eth1 but the incentivation schemes the load balancing of the requests these are areas where we can share the solutions and kind of that ground I'm kind of excited about the possibility of eth1 incorporating leap P2P support in some way this is something that's possible in the future. Okay probably I'd like to take advices 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 eth1 and eth2 I'm actually both care like a lot about the back workability issue like the thing is for like currently like probably all of you know that in eth1 we have a breaking change that creates a lot of conflict I hope we can try to avoid the same situation on eth2 by designing the execution engine better like make it forward compatible 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 upgrade that version is that's how the vibe works that will be how WebAssembly specification works so how do we incorporate those new features adopted in WebAssembly into our WebAssembly execution engine in eth2 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 Rust developer if you are Rust developer and you want to work on eth2 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 the work that's going to happen these incentivized test nets this mainnet launch which is like 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 think it's very exciting to see where it's going thank you.