 We're about to kick off the ethereum one Slash ethereum to transition and I think that Danny is the right person who will introduce you to the topic Yeah, I'm Danny. I work with the theory of foundation on a lot of you two stuff the question of what The existing theorem chain does and is in relationship to the theorem 2.0 has been kind of an open question over the past year as the Ethereum 2.0 protocol has emerged as people have begun to work on it for a while It was Maybe it would be rolled in as a smart contract within one shard That was also floated. Maybe it just exists in parallel forever and we let it die Both of those one of those have seemed kind of complex and the challenges were not so clear how to solve them and the and the other It just letting it exist forever Kind of didn't feel like the the humanist approach as Casey likes to put it I didn't know all of these humans in this room work on the ethereum protocol so It's been a priority to figure out a better way to Slot eth1 into eth2 there's a lot of conversations this week around Execution execution environments and it turns out this like very highly abstracted execution notion of execution Might allow us to more easily slot eth1 into eth2 as it's own execution environment But it's a lot of things to figure out what that actually looks like and then more importantly Even if you do that we now have this We essentially we have all these developer interfaces on how we interact with the existing ethereum chain and one of the big upcoming challenges is How do we take all of these developer interfaces and once we've made this or prior to making this migration? How do we kind of rework the internals of these expose very similar if not the same interfaces such that the developer experience? Is is fluid and continuous through that migration Definitely the this is kind of the lay of the land of the problems. It's the technical problem of how How eth1 becomes any if during that transition? What we what things we might choose to change there's been talks about changing the merkle tree structure How certain things like block difficulty and things like that are translated some of these old opcodes and things might change Do you open up the sharded universe to this to EE and and expose new things to ethereum 1 within ethereum 2? a number of other challenges like that so it's kind of the technical challenges of that migration and then the developer layer challenges of masking the complexity and kind of like Shifting the entire community over Is that the kind of stuff that we wanted to talk about today Okay, cool Shall ways gonna introduce yourself Okay, it's So it's shall we found some foundation research team and I've been working for shorting for a while and now it's two Hi, I'm Alex Stokes. I work on Trinity, which is the Python client sponsored by the foundation Focused on eth2. I've also been looking into some of the research around the finality gadget Which would be one step where we start to kind of merge the two systems looking towards a longer term transition Hello, I go by my online tech Proto lambda And I've been picking up more and more of the testing work for your firm too as the spec across and the work of the earth Hi, I'm Adrian Sutton. I work for Pegasus Part of consensus and I've been working on our eth1 client, which is basu and also our Artemis client, which is eth2 Hey, I'm well. I am in quote. I've been doing phase 2 research And been working on various execution environments and pieces like that Hi, everyone. Yeah, it's like Coming from status research We're in this context working on an eth1 one and an eth2 client Both have been coming Hello, my name is Trent. I work with white block, which is a network protocol testing platform Hi, my name is Cole. I'm eth1 research and I'm mostly working on migrating Validators over to eat you at the moment Okay, I'm not a researcher. I'm kind of just like an angel investor and I also work for circle Hello, my name is Alex and I work in the Russia for us and FinTech Association right now And we are looking at ethereum from the compliance Point of view and developing the software for the national standard cryptography Hey, everyone. My name is Victor. I'm over at bison trails. We help people run nodes And so we currently support 1.x extremely excited for 2.0 invalidation Hi, my name is Joseph. I am an engineer at gopaks Korea's cryptocurrency exchange I'm John. I'm an advisor to gopaks Hi, I'm Justin Drake research at the foundation mostly working on eth2 Hey, I'm Felix again. I work on eth1 so Jason Carver Working with the theorem foundation on the attorney client more on the eth1 side Vitalik, you probably know about me because I already introduced myself on the previous panel And one other component of this migration that I wanted to mention is that EEs and execution environments, which is the notion of state instead execution in eth2 are stateless so there are Depending on the you'd have to have some notion of state in a separate piece of software or something like that. So the ethereum one clients then likely become that interface to the eth1 EE in terms of state And provider of state and sink and things like that. So there's also this component of How geth parody another mind Nimbus things like that That piece of software integrates into this new stack to provide services to the eth1 EE Let's just start with a very basic question What can regular users expect from the transition? How would they be impacted in any sense? in the short term not and Unless you personally choose to take your 32 ether and stick it into the deposit contract and start running an eth2 node and become a validator And and if you do then you'll be able to start experiencing the wonderful world of eth2 early And if you do not then if you do not then nothing will happen eventually there will be some form of eth1 to eth2 eth2 a transition and With the kind of a road map as Danny suggested of eth1 transitioning into being an eth2 execution environment It's theoretically possible to write the software so that you experience like very close to no disruption at all Like though the two kind of the worst things that might that might happen One is that the chain might have to like halt for some period of time to make the transition go smoothly to allow the Miracle roots to be recomputed according to some more efficient restructure and so on and the second thing is as I mentioned In the previous panel gas costs for op-codes that touch State are going to have to be increased massively both for eth2 compatibility reasons and for kind of other scale a scalability reasons as well and so Some applications might have to and have changed the way that they're implemented in order to continue to be optimal so in that and I mentioned it explicitly at the beginning the challenge and a lot of these challenges Cannot necessarily be tackled today The research around phase two although is progressing quite rapidly Especially compared to where we were say six months ago We're not at the point where we're interfacing where we're actually dealing with kind of like the user level and developer level interfaces into these things But when we do cross that road say early next year, it's going to become extremely valuable and important for the maintainers of the developer interfaces the web3 libraries the the developer all the developer tooling to Begin to collaborate to start to Define these interfaces and kind of like realign these interfaces to plug into eth2 so Early mid next year. I think forming some sort of group that of people that do work on these toolings to kind of Get get ahead of the curve because it's going to be important for migration I had a question on the Shift to proof of stake. Are there any specific? Points in time or there really events that are important for this transition in terms of like maintaining the security of the network If it goes more secure less secure at some point and what the parameters are Yeah, so the parameters that probably matter are or the kind of the events that you need to care about One is the time that the deposit contract gets published And so if you're a validator, you will be able to kind of pre-join the other is the time when the chain launches and Basically, if you're a validator, you should be sure that you have a client running at that point And when the chain launches that you'll have a proof of stake chain running The next major milestone after that would be the phase one switch and the phase one switch is important Because that's the time when shard chains will turn on and so that's the time when Especially if you have a lot of ether your computational requirements will increase like because your computational requirements will basically be Proportional to the amount of ether you have the more ether you have the more validators lots you have and so the more Shard blocks you will be called to make a cross link on and then After that and there will continue to be forks, but kind of the general way the chain works will continue to be Fairly similar in and then after that, of course the ease one to ease to merge the details of which haven't been fully figured out yet So in that roadmap, we still don't have a way to Exit from being a validator. That's okay. That's a significant thing. No, that's that's a good point. This is something I missed in phase One or two not fully decide not fully decided if will become Transferable the kind of default roadmap is that if will become trans it will become Transferable and more and more people just wants to have their if on the if two side I mean if desired There's also of course the alternative of like making an explosive if you back to if one bridge, which of course I can absolutely be absolutely be done, but it's something that dick Is extra work as well so Yeah, I'm thinking of the scenario where sudden where you buy in and phase zero and suddenly you end up with lots more Responsibilities in phase one that you realize that you cannot can no longer support so first of all you can withdraw and you can just have your eats sit there and What when transfers are implemented then you could also just sell your ether to some to some whale or Just anyone Like there's probably going to be a bunch of like basically If the like the thing is right that if the price of kind of ETH on the ETH to a side kind of goes Below the price of ETH on the ETH one side by even a tiny amount Then everyone who would have joined by joining through the normal process would instead wants to join by but just trading Their ETH one for a little bit more to and then joining directly from the ETH to a side so there's this kind of Natural demands pressure that you would be able to treat to a kind of trade into and you would In order to convert your ETH to back into ETH one side ETH if you want to And if this natural pressure is is too weak in practice Then you know it's possible that the beacon ETH will go lower But then the bigger the price discrepancy the more of an incentive it is for us as a community to To build a two-way bridge so in a way it's kind of self healing because The possibility of the bridge will reduce the gap The the the suggestion was to commit to doing the bridge and then kick the can down the curve for as long as possible I so some of the Like preferable peripheral work that we can do to unify these systems and kind of give value out of the systems Out of out of ETH two in ETH one I think the decision on whether to actually do this work is probably contingent upon where we're at with ETH two at any given point so I I Mean we can commit to if we if we need to do it will do it but More importantly, I think kind of assessing it's always like it would detract It would it would take work and take effort and take You know focus away from shipping ETH to the more that we kind of income encumber the two systems together and we have made a commitment because Like once we have the native integration that is a two-way bridge I guess the question is do we have something in between which is a High latency two-way bridge as opposed to a really fast native integration a Hypothetical question if it's If it's gonna cause a contentious hard fork on ETH one to make a bridge from these two back to ETH one is Is it still something that that you would so okay? The scenario here I'm thinking is that okay ETH two happens and something really bad happens and a bunch of extra Ether gets created and then this kind of price discrepancy happens And there's a demand to make this bridge to return the best to the S chain So the nice thing about phase zero and one is that it allows us to architect the system this Complex in many respects system in a production context, but without having users yet so if some underflow happened and we had 20 billion ETH created we'd likely fix it The because it's an early system. There's not that many users. The only users are validators And that's one of the that's one of the reasons that transfers aren't enabled necessarily in phase zero, but There's a class of bugs where it's not explicitly a problem, right? That you can't have this kind of misaligned incentives or something and they can be either created and some people say Oh, this is totally fine. This is part of the protocol But other people say no, this is a serious problem and it's difficult to tell the difference between the two Not in a way that would generate a bunch of ether There potentially slash like mate like if if half of the validators that got slashed You could see that being very contentious, right? If it was some sort of like bug in the software and things like that, but Ten times the supply of ether being created is like explicitly not an intended portion of the protocol So but I I hear you I hear you the more that you encumber the systems the more that It's becomes more difficult to Fork or maneuver one or the other or the more that politics over here might affect politics over there I have a question when you're thinking about design a bridge How much of your consideration is around the work that it'll take to implement it versus the like social construct of like being bought in and having no way to leave I I My personal opinion is that like generous part of us I think like having a social like having it be two way is somewhat better than not having it be two way the reason We're not in through like enthusiastically going toward implementing the bridge on day one is because it legitimately is a lot of a lot of work and like if And in the happy case, it's work that we expect that we expect to never need But I know people's people's opinions on this might on this might differ right and for better or worse each one takes a lot of time and effort to Fork and get things in and so the longer that we can Operate in ETH to very rapidly and it can iterate quickly The quicker we can get things out and kind of get to the vision the sooner that we choose to Tightly couple these systems. The harder it is going to be rapidly Iterate and get out these phases of production. So Definitely a trade-off there. I think the other aspect that that I quite like and you know at risk of disagreeing with Vitalik Is there's a real incentive that people are excited about each two and and so I want to get in and stay And there's been a real incentive to actually make it work and go all the way and get main net over to it If that's the only way you can then really use that if you've just put in so Kind of having it locked up is is nice in some ways It makes it a little harder to sell people on the idea of becoming a validator But once you manage to get them over that hump It's kind of downhill in terms of getting them to support moving forward, which is nice And if we want to go full to or die then we can change the deposit contracts So instead of locking the ETH forever it becomes accessible by the Dow Hacker on January 1st, 2027 Yeah, just given liquidity alone Can't we expect a illiquidity discount on the ETH to either and if you're one-to-one? Burning your ETH one ether and then creating one ETH two Yeah, I mean a decision is made there and it's based off of how much you're expecting to generate in New ETH two as being a validator But granted it's a very complex Right, right, so you might you might expect some sort of discount for some time horizon but if your time horizon is longer than That with which the systems are merged and unified then you don't really need to necessarily You don't externalize that that discount for the time. So I do expect early validators to be hobbyists, enthusiasts, long-term holders And I expect them I expect them to get probably higher return than when these systems are unified And there's more institutional players and a lot more people kind of willing to accept a different risk analysis. And so Honestly, I hope that it's a boon for hobbyists. I hope that it's a boon for people that are like deeply Invested not just financially but like invested in the technology and believers in the technology What are the right conditions for the ETH one folks look at using the finality gadget like implementing the finality gadget? What was the question sir? What are the right conditions for us to start talking about implementing the finality gadget back from beacon chain to the main chain? conditions the technical conditions or There's really two things one is one is the technical and two is understanding like better understanding the time horizon of phase say phase two if phase two is a Hundred years from now we should implement the finality gadget if it's two months from now We probably shouldn't and then somewhere in between. There's a there's a line There's it doesn't have to be like we as in everyone right like a finality gadget could like there I think one of the reasons Jason's asking is that is doing the Python client and Python is Slower than other languages that executing history and so if you got a finality gadget you'll need to check like five hours of history Which is really nice Yeah, yeah, yeah, I think it definitely be an off be kind of optional and of light client type thing that you can do Question so going back to the question about I guess they have the first two phases before or like a with regards to building the I guess either one way or two-way bridge between ETH one and two apologies if this is orthogonal, but Within the risk analysis. Have you guys considered let's say some central as exchange just basically say create or Allowing and facilitating and encouraging their customers to basically deposit their balances into the deposit contract and basically creating this like weird futures ETH 2.0 Like market before there's even like on-chain liquidity and like if you guys consider that or is that just completely orthogonal to the rollout I guess like what should we one question with that is that like if there was a kind of futures market for ETH 2.0 ETH then like why would anyone I guess like Voluntarily participate in that construction because like if that if the price is if the price is lower than one Then you'd see why people would want to buy but if the price is lower than one then like why would you even? Wants to kind of move your ETH onto these two side and lock it up unless you're also going to be a proof of staker I guess like at some point I think like transfers on the ETH 2.0 side are going to be enabled and so like a price between the two sides is going to Exist and like I do think there will be I do think there will be a lot of pressure to kind of push that price to be very close To or equal to the one level Any other questions? Can you please come over to the front because we have cables and we can like Have there been any considerations of like Test net implementations for some of it We're testing the the ecosystems whether they're like a deterministic test net or possibly like a like a confrontational test net where you know, you know actors are incentivized to try to Disrupt the network as much as possible or just any any ideas around that front these things are certainly on the horizon and after the interop Workshop where we're kind of doing initial interoperability testing That is definitely a next phase Although some private more scaled-out networks are probably on the immediate horizon before we open it up But I'd certainly like to do some adversarial stuff. I've had a couple of conversations with some guys at Cosmos to hear about their experience over there For better or worse we have a lot of clients So some of the complexities of doing that and managing the complexities of many implementations of the software in these public test nets I'm gonna be interesting. Yeah, and I think any equivalent to what we did with them Olympic in 2015 with incentives to dust a hell out of the thing would be great Have a name to Dan from corn base. Hi, Dan. Hey, have a talic I'm curious what's your what's your mindset is around leveraging exchanges and other entities to migrate if 1.0 to 2.0 in terms of adoption I guess like in the first question is kind of what role exchanges would have right because Like the default process for moving ETH over to become a validator doesn't really require any kind of special third parties And I guess like in the case where there are if two people that wants to migrate back to the ETH one side And then there's these one people that wants to deposit then you could kind of act as a matchmaker between those groups and create an easy interface for that Yeah, I certainly expect when transfers are enabled on the beacon chain for exchanges to kind of step up and and provide liquidity options to validators and Kind of expect y'all to do that Are you gonna help organize that I just expect us to do I've talked to people at Coinbase, so cool But I don't know I kind of explaining especially when transfers come into Existence having literature maybe focused for exchanges to better understand what's going on Would it help enable exchanges to enable our users? So yeah Thank you. Oh Sorry, can we expect ETH to ETH to be traded as a separate token? That's the exchange's decision. Yeah, well, that's what I'm saying like it's an especially in an exchange decision Like we could have exchanges this Yes Okay, yeah, sorry, I didn't mean to be like blunt But yeah, if an exchange were to like similar to I guess BCH for the fork for that like yeah, okay. Yeah Thank you for your answer Yeah, I mean the thing to think about there is ultimately whenever you've got anything that's a deliverable currency You have to be able to deliver it to the right place. So if ETH to an ETH one is separate and you can't transfer back then Anything doing deliverable trading absolutely has to trade ETH to as a separate thing to the ETH one If it's non deliverable, you can get more fancy and people in finance like to get fancy But I won't try and speculate on that Well, I will say one thing about if you look at existing like SAFs and OTC markets like there's already like well established processes and guidelines for how people to trade these liquid like Promises essentially and so it's not out of the question that the same thing would happen for ETH to as long as some liquidity providers or strangers were supporting it So the reason why I asked this question is because I feel like you know from a like regular human standpoint It would make sense if you know like the transition would be kind of seamless, but It's clearly not like it is like, you know, like it's it's it's also an investment opportunity and you know So there are certain issues there, which I feel like it would be maybe that would be one Reason to like go for the bridge like right away So we wouldn't have this problem even like from it just from a user standpoint Like they would be really clear that like, you know, we would never get into the situation where you kind of like gamble with like ETH one versus ETH two on an exchange So one instead of right away another option right there is At the moment that transfers are enabled so anytime at the moment, there's liquidity an option on ETH to there being a fungibility option and that's that's interesting I think that um, there's many factors at play here, but looking historically coins like zil or like what dies about to do There's a lot of a lot of things going on here It's hard to predict but looking at previous coins that have migrated to other blockchains that that support their old blockchain as well their new blockchain such as zilica and and die They set precedent for what can happen here or what can't happen here Um something that's really interesting Coming out of this conversation is at least the people that are speaking it seems like the biggest concern is Value and liquidity and all the questions around the token stuff. Yeah. Yeah, okay Is that not is that representative of everyone in the room? Who cares about value? I Mean you can care about value, but there's probably other someone said no. Yeah I'm very and I don't think that it's representative of the group I think that the people who are sitting closer towards the front self-selected as as like having having some kind of Strong motivation to interact in this conversation bigger bags and the strongest motivation a very strong motivation is a financial motivation Except for me. I just sat here I will say something that I'm very curious to hear is how much of the work that is being done for ETH 1.x is reputable So if we're like pushing back state rent and it'll get implemented Let's say like a year or two from now like is it an easy drag-and-drop onto 2.0 or will we have to rehash a lot of the same issues it's a And the ETH 2.0 kind of core design is designed around any state minimalism And so state is a kind of somewhat higher level a level concept and consensus But like basically all of the stateless client work that's happening on the 1.x side is I've also simultaneously work that prepares ETH 1.x for and if being a Transplanted into being an execute into being an execution environment inside of ETH 2 I Can also say that from a technical point of view like a lot of the work that we've been doing is kind of like shared in Between like you know the clients. I mean after all we do share like for example We are making like the goal-based ETH 1.x client and there is like sharing of libraries going on with the ETH 2.x Implementation so it's not These projects aren't completely separate when it comes to the actual tech is more like they are Conceptually different of course and they do implement different protocols and they are different products in a way But the software is there is a lot of sharing going on and the same can be said about Trinity I guess because it has both so it does share a lot of code Tacking on to that question and like between ETH 1 and 2 we're Doing the same thing but changing everything so we're changing the consensus we're changing the networking protocol We're changing the execution environment And we're changing the cryptography. What do we hold constant? I mean the fact that like current applications will continue to Work through the trend through the transition kind of as is like modular concerns about opcode repricings I think is like one major thing I have a question about clients So we have what seven clients in development for ETH 2 would there be a efficiency to be gained if Efficiencies to be gained if we had less client teams and more work being done on Getting to the end and also a second part of that is If there are seven clients the performance of the blockchain is going to be held back by the slowest one So that increases the the chance that it's not full performance, right? So If you could take all of the people working on all the clients and put them on half the clients maybe so These are independent companies and entities that you can't necessarily just do that with that's just a cat herding problem Come on. Yeah That said There's probably diminishing returns after five, but we've had kind of an incredible amount of Technical sharing and idea sharing and and I think it's actually have been a boon to the process in many respects With the upcoming test nets and move to production I do have some concerns about managing complexity and managing user expectations on what which software to run, right? It's it's hard to know it's hard to choose and we will have To speak to the second question Metrics minimum set of criteria that to be production ready. So if you can't handle a state transition with Four million validators and under this amount of time Then like you don't get the check in the box and you're probably not ready for production and that'll be very clear to users And so much better to have three great clients then seven that may be not all of them are great Right, and we probably will have three great clients And maybe more but we will certainly have three great clients So I think we end up in the same spot Last question, please I was just gonna add to that that one of the problems we see in each one is that Geth is so popular that we're gradually kind of converging and a lot of our gas pricing is based on gets performance Which is good and gets a great client, you know But one of the advantages of having so many clients initially in each to is it is it helps us avoid that? Centralization so we do are much more likely to stay with a good broad range of clients with a broad range of approaches to solving problems Yeah, I'm really hoping that We don't have any client with over 50% of the network. I think that's really valuable to the security network and I We will see how many actually launched with Bay zero as production ready. I'm not I'm not sure So the problem with each one that that a minority client managed to slow down the network Until it well in each one We also saw that a minority net client managed to speed up the network, right like one that in a particular instance Yes, in a particular very important instance that what otherwise have killed us