Anna (00:00:05): Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week James and I chat with Ben Edgington, lead product manager for Teku, an Eth2 client. He walks us through the Eth2 timeline and how the ideas around this massive upgrade to the network have evolved. We chat about the plan to merge the Eth2 proof of stake system with the existing Eth network and how these two chains will work together, going forward. We also look at how L2s could potentially interact with this new setup. Anna (00:00:53): Now, before we start off, I want to share a quick tip to anyone who's thinking of jumping into the zk space professionally. We actually have a ZK Jobs Board on the website. There you can find new opportunities to work for some of the best zk projects in the space. I also want to remind you to sign up for the monthly newsletter zkMesh for all the latest on zk research articles, tools and tips. We send this out at the beginning of every month. So that's the ZK Jobs Board on the website or zkMesh. And I've added the link to both in the show notes. This week's episode is brought to you by Mina, the world's lightest blockchain. It is a project deep in the zk space and one that I am currently advising. Also the Zero Knowledge Validator is actually a validator on Mina. Now, Mina is a layer one crypto protocol that replaces the traditional blockchain with a zero knowledge proof, ensuring a super light and constant sized chain that allows participants to quickly sync and verify the network. Mina offers a platform to build a private gateway between the real world and crypto. The project has an active demo in partnership with Teller Finance for “End-to-End Data Privacy”, showing how you can use Mina to access your credit score and prove that you meet credit threshold requirements for on-chain services, without ever disclosing your actual score. This is an amazing example of the power of zero knowledge proofs. Visit minaprotocol.com to find out how you can get involved and be sure to join the community there. So thank you again, Mina protocol! Now here is our conversation all about Eth2 with Ben Edgington. Anna (00:02:27): So today James and I are here with Ben Edgington. We're going to be talking about the state of Ethereum. I'm not going to say Eth2, I hear that there's some conversation about what is and what is not Eth2, what is not Ethereum. Hopefully we can jump into that, but welcome to the show, Ben! Ben (00:02:49): Thank you, Anna. Thank you, James. I am honored to be here. Long-term fan, really enjoy your... Your output is great. Anna (00:02:57): Thanks. James (00:02:57): Thanks so much. Anna (00:02:58): So I know I keep referencing this, but we're coming off of this 6-part L2 series that James was part of most of that. So it was basically through that series, I started to realize like I'm completely out of the loop on what's going on on the base level. I know that we had Danny Ryan on last year, maybe two years ago, talking about the Eth2 roadmap. I've had a few people on maybe last year that gave hints of it. But I think this is the first time in a long time that we're going to be digging into the state of Ethereum and, having read some of the stuff you've been writing, I feel like you're the perfect person to do this. Ben (00:03:38): That's very kind, I don't know about perfect, but I can certainly help guide you through the maze and you can be forgiven for not being up to date, because things have evolved, things have changed. And it'd be good to talk through some of that. Anna (00:03:52): Cool. To start off, let's hear a little bit about you, what was your journey to Ethereum in the first place? Ben (00:03:59): Well, where to start? I had a very conventional career, to a degree. So I studied mathematics at Cambridge, spent seven years there, somehow managed not to emerge with a PhD, but three Master's degrees. They tried to teach me group theory and I was highly resistant, which I regret now very much, as I'm catching up now. I spent three years at university of Reading, working on supercomputer implementations of weather models, that kind of stuff. And that got me into the high-performance computing thing. I went to work for Hitachi, the massive Japanese multinational, first 10 years or so working on supercomputers and then branching out doing a lot of FinTech staff, data center staff and healthcare, and all sorts of crazy things, biometrics... Anna (00:04:49): Did you actually work in Japan? Ben (00:04:50): I visited Japan many, many times, but I never spent more than a month or so at a time in Japan. I love Japan, it is a terrific place. Anna (00:04:58): I know James loves it too. James (00:05:00): I am a huge fan of Japan. We did live there for a couple of years. Ben (00:05:04): Oh, wonderful. I envy you, it's great. So I spent 19 years at Hitachi, had a very conventional career, wore a suit and tie everyday, ended up moderately senior, head of engineering for a group working in FinTech stuff in the UK, the territory was Europe, Middle East, Africa, North America, traveling the world. But I just got to a point where it wasn't... Writing spreadsheets and doing budgets and hiring plans was just not intellectually stimulating. So there just came a point where our sales people were coming back and saying, "All our clients want to talk about is something called blockchain". This was early 2016. "Ben, can you tell us what it is?" And I was "Okay. Let me look into that". And then just fell down the rabbit hole, it just became an obsession. So Ethereum was one, it was proof of stake that hooked me and it started consuming all my evenings weekends, and then eventually, one way and another, I've got an offer of a place at ConsenSys, which is where I am now, have been for getting on for 4 years now and landed in the protocol engineering group, which is a wonderful place to be. Anna (00:06:16): Stylewise, was this a huge shift? I can imagine it would be. Do you still wear a suit or..? Ben (00:06:23): Tempting, tempting. Everything changed. I mean, it was proper midlife crisis stuff, it is a well-kept secret. I mean, between today, between recording and this podcast going out, I shall turn 52 years old. James (00:06:38): Congratulations! Anna (00:06:42): Yeah. Amazing! Ben (00:06:42): I'm not sure congratulations is quite the right take, but you know. And at that stage it was kind of comfortable path to retirement or do something crazy. And I'd sat on the sidelines during the dot-com boom, all the people I worked with had gone off and joined start-ups and had the time of their lives. And I sat through it, being very conventional. And I thought, "This is the chance, this is the last chance, let's grasp it". And everything changes and I love it. Anna (00:07:13): Cool. James (00:07:13): That's awesome. Anna (00:07:14): Was 2016 when you actually started at ConsenSys? Ben (00:07:16): No, 2016 was when I first became aware of Ethereum and started getting into all that. It was a year, year and a half later that I joined ConsenSys. Anna (00:07:26): Got it. So you would have joined ConsenSys right during the boom time, it sounds like. Ben (00:07:31): Yeah, that's right. I mean, we were growing phenomenally, so I was employee something like 350, and then six months we were at about 1100, it was insane. I spent the first three months just interviewing constantly and grew large and, I mean, we know what happened. The bubble burst and we shrank down to 303, back to 350, I don't know the exact numbers anymore. And yeah, it was a bit tragic, not easy things, but in this volatile market, this sort of thing is inevitable. We are on a nice upward curve again now. So lots of hiring, hiring for my team. So we'll talk about what I do in a bit, I guess. So if anyone's listening and has Java chops, get in touch. James (00:08:22): Riding ConsenSys all the way up, and then all the way back down, must've been a wild experience. Looking at it from the outside, it seems so interesting. Ben (00:08:32): It was a fascinating time and ConsenSys has changed a lot and that's an interesting topic all of its own, but we had the motto when I joined them for maybe the first year, year and a half. Pretty much the internal motto of the company was "Everything is an experiment". And we were trying wild, new governance models, internal governance, flats, structures, tokenization models for incentivizing, all sorts of things, really, really trying to walk the talk. I think it can be faulty to an extent that we rarely completed experiments. We started many, many of these things and didn't really push through and see them through to a conclusion, which is a pity, but it could have been a different paradigm and now ConsenSys feels a lot more conventional. It feels much more like where I came from, we're in a different area now. Anna (00:09:25): And there have been some winners that have kind of shone through, I feel like there's some projects that are so, so key to the ecosystem today that come out of there. Ben (00:09:35): Yeah, absolutely. And things like Gnosis that have spun out ages ago from ConsenSys as well. So there's been plenty, over the history, and there's a school of thought that this is a decent approach to innovating and creating value. You start many experiments, it's evolutionary, you kick off many, many experiments, explore the landscape, and then you've got to kind of kill off your baby, play a selection function to it. And then you end up with the strong, the survival of the fittest, and that's kind of how it's ended up. Though it can be a bit brutal on the journey. James (00:10:11): Well, I think that in that way, it mirrors the development of Ethereum in a lot of ways, going through this extremely grandiose high concept experimental phase, and then pulling back a little more recently into more directed engineering and to actually delivering on some of the early promise. Ben (00:10:30): Yeah. And, this is one of my passions really, is the how does Ethereum get things done, sort of way of looking at things. I like to feel I'm a little bit of a historian or kind of commentator on the distributed development model. And it's been really interesting to see how things evolve and ConsenSys was not a traditional start-up by any means. We were, Joe Lubin was awesome in just funding everything initially and just really bankrolling the whole experiment. Things are different now, but he wanted to make a difference genuine and really put his money to work in that respect. So that was great. And I guess we have the Ethereum Foundation playing a little bit of a similar role, but certainly not the same. Anna (00:11:21): This is sort of a side, but is Gitcoin originally a ConsenSys company or project? Ben (00:11:27): Yeah, it just spun out. So that's right. Gitcoin, it was incubated, that's one of the old, old experiments and that's wonderful, that's terrific how that's come to maturity. Anna (00:11:38): So the Zero Knowledge Podcast has had a grant on there for some time and I've always been amazed with the scope. They themselves also almost act like ConsenSys. They have so many experiments. When you go on their website, there's like grants and bounties. I mean, I'm not actually following what the latest is, is there now governance, but there's a lot going on there. It kind of mimics where it comes from, but one of my favorite projects, I think in the space. Ben (00:12:03): Totally, totally. Anna (00:12:03): So let's dive into Ethereum, because I think that's what you're here for, that's what I'm curious about. James, I feel like you probably are keeping more up to date with all things Ethereum, so I'm glad you're here. James (00:12:21): I try, but there's an awful lot going on. I'm gonna take a second, plug Ben's newsletter, which is one of the best ways to keep it up to date. Anna (00:12:31): Oh, what is that? Ben (00:12:31): Right, yes. I've been writing this thing "What's new in Eth2" for about two and a half years. It sometimes feels like, sometimes you regret you started something. I don't know if you ever feel like it with the podcast: "Oh no, not another one", but... Anna (00:12:47): I'm pretty used to it now. Ben (00:12:50): So every two weeks I try just to summarize what's going on. It started off very technical. It was really aimed at the devs. Nobody else was paying a lot of attention at the time. And as a way just to keep myself honest, force myself to read everything that's out there, keep up to date and just a forcing function to make sure that I was doing my job. And I write that every two weeks, you can find it at Eth2.news, and I just publicized it on Twitter, I don't have a mailing list, I'm far too lazy for any of that stuff. So follow me on Twitter and then you find that. There is an RSS feed that I maintain. James (00:13:26): That's nice. Anna (00:13:28): Okay. So let's go back to your story. You're working at ConsenSys, you're hiring a lot, but then at what point do you start to work really on what was called at the time the Eth2 roadmap? Ben (00:13:42): Yeah, so I started at ConsenSys in October, 2017, I spent the first 2-3 months thinking I was going to be doing Enterprise Ethereum stuff, but don't tell my colleagues, it bores me witless. So I just had these crisis moments, "I want to work on mainnet stuff. This is my passion. This is what brought me here. This is where I want to spend a hundred percent of my time." So I talked over my colleagues and they were super supportive. So I had a mandate and that was cool. I spent the first couple of years actually building the R&D team. So my work was to assemble a team of research and development people with short and long-term horizons. And that was a joy. I mean, just the opportunity to assemble brilliant people around me and let them work on what they felt was important. And we have zero knowledge group that's building a library Gnark, which is written in Go to do zk-SNARK-implemented language, it's very performant. Anna (00:14:47): I've heard of that. That's come up in the zero knowledge chats in the past. Cool. Ben (00:14:52): Yeah. That's one of the things. And moving into more Eth2 scaling stuff. So my colleague Nicolas Liochon was an early hire and we got together and we got interested in, what does the future of the Ethereum protocol itself look like? So we attended this scaling Ethereum event in Taipei in early 2018. It was basically around sharding and what do we do? And at that point, the plan was to do everything on the base chain. So Danny Ryan was working on putting the management contract for proof of stake on the base chain, so it would just be the standard smart contract, there was a testnet for that and so on. And we thought we're going to do sharding the same way. We were looking at putting a sharding manager contract on the base chain. And so all the conversation at that event was around building out proof of stake and scalability on the base chain, using contracts and the Turing completeness of Ethereum to do everything that was necessary to make it happen. That'll change and we can come back to that, but it wasn't even Eth2 at that stage, that was the Serenity play. We upgrade the mainchain using its smart contract capabilities. And then this is the final goal, we're at the end point, the Serenity. Anna (00:16:12): This is reminding me of another episode that I think I did 2 years ago with the Prysmatic team, because it was in that episode, where I learned one shift from that original idea, which was the idea of building an Eth2 separate, that was like a separate sharded blockchain. And that there was going to be a way to almost lock in Eth1 as one of these shards or something like that. I remember there was this idea, that actually it was a total new standalone project. So you were there during this phase. What would you call, what is that era of the Eth2 roadmap? Ben (00:16:45): I call it the Serenity years. Anna (00:16:50): That's still the Serenity ones, even when they had the separate one. Ben (00:16:52): Well, so we're coming to that. So at this point we're still on the original trajectory and this is how it's supposed to work out. So got interested in that, started working on that. And then around June, 2018, we all met in Berlin and it had basically a sync, you know, before the meeting, we had realized that this had many flaws that we weren't going to be able to solve. So we basically ripped up the whole thing and started with a blank sheet of paper, a blank HackMD document in mid 2018 and just said, "Okay, we're going to build a different chain. We'll leave Ethereum as is and alongside it. So that's the kind of single track cartway. And we're going to build this super highway alongside it, running on proof of stake. And at some future date, we will migrate all of Ethereum into this new super highway infrastructure. But they will run as two separate projects for the time being." Anna (00:17:50): Got it. And that was what the Prysmatic team had come on the show to tell us about. Ben (00:17:55): Right. Exactly. So that's the Beacon Chain, I call that "the Beacon Chain era". So that's what we started there and that inspired the language. And some of the design features were inspired by the Dfinity blockchain, they just published their paper using BLS signatures to do committee management and stuff. Anna (00:18:17): That was the last time they had published anything publicly for many years, until recently. Ben (00:18:22): That's right. I don't think they like this lifting veils thing. Anna (00:18:25): They completely went dark. James (00:18:27): I remember that week very well, because I was in Berlin for fun and kept running into people and getting pulled into design sessions for these things. Ben (00:18:37): It was a great week. That was fun. James (00:18:39): It was a good time. Anna (00:18:41): Okay. So now we've covered "the Beacon Chain era" or we're in the Beacon Chain era. James (00:18:46): We've started the Beacon Chain era. Anna (00:18:47): We've started it. What happens in the Beacon Chain era? Ben (00:18:51): Yeah, so we should look at some of the motivations for ripping up the old design. So part of it, mostly it's around limitations of the base chain, we would have had to have made protocol modifications to favor protocol transactions. So instead of just running smart contract, DeFi stuff or whatever on the base chain, we would have had to start running protocol stuff, sharding management and proof of stake management on the base chain that would have had to have privileged messages, because you can't neglect running the protocol, because everything depends on that. And that meant quite a lot of changes on the base chain. You couldn't do it all in a smart contract in short, we would have had to change other things. And also the capacity of the chain was not sufficient. So we could have only sustained a limited number of nodes, we were looking at a minimum stake of 1500 Ether at that point, to put a cap on the number of validators on the network and that really, even at Ether prices in those days, that was going against the spirit of trying to bring in the broadest range of stake as possible. Anna (00:19:59): Wait, 1500 per stake. That's what somebody would have needed to stake, that was the minimum. Okay. That's pretty high. Ben (00:20:07): Yeah. It was a finger in the air number, but it would have been of that magnitude. And the other thing was that we realized that the sharding and the proof of stake, the consensus, both relied on having stake, on having slashing and had a lot of common mechanisms, committees to manage, a lot of it was in common. It didn't make sense to run it as two separate protocols. There seemed to be a lot of synergy in bringing them together so we could organize. In order to do sharding, we needed committees, but it turns out committees are pretty handy for doing the proof of stake and making that manageable as well. So we were able to combine a lot of the work and just make the whole thing more coherent, more efficient. James (00:20:49): The Shasper roadmap. Anna (00:20:50): Oh yes. Ben (00:20:52): We don't say that. James (00:20:52): It was never my favorite name, but, you know, sharding plus Casper. Ben (00:21:02): Right, exactly. Sharding plus... We are on Gasper now, we have the consensus mechanism as Ghost and Casper. So this is Gasper, there's even a paper about it. Anna (00:21:14): Actually, yeah. We actually did a whole episode on Gasper, 2 years ago maybe. All of these links by the way, I'll add in the show notes in case anyone wants to revisit those. Ben (00:21:23): Yeah. So lots of good stuff just kind of converged at that time, some brilliant minds somewhere. I mean, Danny Ryan got involved at that point as a project manager, but without authority, in a sense. I mean, only the authority, which the people he was managing as teams allowed him to take. But it turns out that he's very trustworthy and makes very good decisions. And so people trust him a lot. So he's more of a coordinator, but really spark, made the whole thing happen. Justin Drake had come in earlier that year with a lot of new ideas in terms of the cryptography. And I think it catalyzed some new thinking that really helped. Protolambda came a little bit later, as Diederik is just brilliant at algorithmic things and helped really shape the spec and the testing and work with the client teams to make efficient implementations. So that was good. So from that June point, client teams started getting involved. Danny says now it was probably too early. I don't know, but the Prysm team were already up and running, they were trying to do a sharding implementation, they were running it on Geth, had a fork of Geth. They pressed on with that for a little while after the Beacon Chain idea had taken hold. But eventually they abandoned that, because it was not going to work based on Geth, it had to be a fresh implementation, they started Prysm at that point. We came in writing codes in ConsenSys in my team around October that year, if I recall correctly. Anna (00:23:04): This is 2019? Ben (00:23:05): 18. Anna (00:23:05): 18 still. Okay. Was this the time, because I remember there was this explosion of clients, was that around this time where there was like 12? Ben (00:23:16): That's right. It might not have been ever quite that many, but there were at least eight relatively serious. James (00:23:21): That year EF funded at least eight. Ben (00:23:24): Yeah. And we didn't receive any funding for us. So that makes nine. Anna (00:23:28): Wasn't there one that was named, something to do with Kanye? James (00:23:32): You're thinking of Dean Eigenmann, Yeah. Ben (00:23:37): Exactly, Yeeth. Ben (00:23:40): He was writing that in swift with Eric too. I don't know. I think it's been shelved for a while. We'll see. He might revisit it one day. James (00:23:50): Well, it's interesting to go back over this, because so few people were around and tapped into this when it was going on. And me, as an outsider, and Ben, as an insider, on this have very different experiences and good overlap here. My take on all of this happening, like the June, 2018 meeting in Berlin and going on to implementations, was basically that relatively competent organizers and coordinators like Ben and like Danny got involved and just completely transformed the whole research process. Ben (00:24:30): Yeah. That's kind to say, this tension between research and delivery is always interesting in any organization. And it's hard to get right. I mean, a lot of cycles were "wasted", whether wasted or not, I'm not sure, but rewriting code. And all of the teams have rewritten hundreds of thousands of lines of code, and Prysm more than most, because they started first, but it's all part of hammering out the protocol. So the protocol was largely built and designed by the EF research team. So it was Danny, Vitalik, Justin, Hsiao--Wei, Protolambda were largely shaping the protocol, but with feedback, everything was in the open. It started life in a HackMD doc, which was horrible. Eventually got migrated to Github, had all the comments pulled out and deleted , so it was just Python code. And this is kind of controversial. I mean, the spec is Python, standard Python code. You can run it with Python and Proto has a framework, where you can just execute the spec. And this is very cool in some ways, because implementers understand this, and you can generate the test cases directly from spec, which is super useful for any issues that arise. But there was a process of purifying it and all of the rationale and everything was ripped out. And I've tried to reverse this. I've got an annotated spec thing, which one day I might finish, we can put the link in the show notes. Vitalik has also done similar as well, just to try to recapture, done a lot of Github archeology on why is this constant set at 64 or why was this design decision made, and not that one, or how did this change over the development of the spec. So for future generations, when they come to this thing. Anna (00:26:30): So that is the archeology going, but it's the comments, you're saying, it's the comments that would have given the context and without them, a lot of this is lost, so you have to refind it. Ben (00:26:40): Yeah. I don't know what the reasoning was there on that, but it is basically just lines of Python now, which is not a terrific spec language. I mean, it's not strongly typed, which is something I would prefer to see. It doesn't lend itself directly to formal analysis. So part of the ConsenSys research team, some of the team I put together, are working now on rewriting the spec in Dafny, which is a formal specification language, and it comes from Microsoft. They believe it's one of the, I think they said to me, it was one of the three largest Dafny projects that have ever been attempted. And they are proving formerly verifying the Beacon Chain specification. And I've got another colleague in R&D, Alex, who has a transpiler for the spec. So he transpiles it into Kotlin and that helps him to identify issues with typing and things, which helps. So there's a lot of work going, or spinning off the spec just to make sure it's all sound. Anna (00:27:47): So this is still the Beacon Chain era. Now I'm very curious, because if there's been an evolution, are these things still useful? Ben (00:27:58): So the plan was 3 phases, 0, 1 and 2. Phase 0: Beacon Chain. We deliver proof of stake and it just sustains itself, it doesn't do anything. I can't transact with anyone on it, but it sustains itself. And we built that, we delivered that, went live last December, December 1st, it's been running 6 months and has been almost incident-free. We had a minor wobble a few weeks ago, but apart from that, it has performed superbly. So we've proved we can do proof of stake under relatively benign circumstances. Now, the plan was then to build sharding, Phase 1, so data shards to bolt them on. And then Phase 2 was to make the shards executable in some way, so that you could run sharded smart contracts or whatever. And then finally to: we have this fully functional Ethereum-like chain running with scalability, proof of stake, and then we import all of Eth1 onto that. So Phase 0, Phase 1, Phase 2, we delivered Phase 0. Since then things will change. Anna (00:29:02): Okay. That's that's where the change happens, whoa! James (00:29:06): That's even a relatively recent version of the roadmap, as well. The phases have gone through a few iterations over the years. [It] used to be, I remember the original 7-phase pie in the sky roadmap. I think the 3-phase is much more reasonable, but my recollection of the original 3 phases was Beacon Chain, sharding and then execution on the shards, with the Merge being a separate, out of the main roadmap, piece. Ben (00:29:38): Yeah. I don't think we ever really nailed down, this was part of the problem, we never really nailed down what the later phases would look like. There were teams working on this. So within ConsenSys, we had the Quilt team, who is still around, they were working on what would execution environments look like in the sharded world, looking at eWasm. James (00:30:00): I remember a design session in Brooklyn a couple of years ago with execution environments. And it was good. Ben (00:30:08): Yeah. A lot of cool ideas, but in the end, I think the design space was just too big, the problem was too poorly specified. James (00:30:16): And the overhead of adding a second interpreter in is pretty large. Ben (00:30:22): Right. I mean, he was, despite hopes for it and a lot of people were looking for it, I don't know exactly what the issues were, but there were things around just-in-time execution not necessarily being reliable, about not being able to do crypto quite fast enough and things like that. So maybe these were surmountable issues, maybe they weren't, but in the meantime, other things happened and changed the roadmap. Anna (00:30:50): Phase 0 happened, now we're talking December 2020? Ben (00:30:54): Right. Anna (00:30:54): Okay. So that happened and that amount that you had said, the minimum amount, that you'd have to have in order to be a staker on Eth2 at the time, obviously went down profoundly. It went down to 32 ETH and people have deployed, people, they're locked in. So Phase 0 is out and they've locked in their 32 ETH. Ben (00:31:22): Correct. Yes. We have 160,000-ish of validators deposits, as of today, which is over 5 million Ether, whatever, 10, depending on the day of the week, 10 billion plus dollars worth of ETH stake. It wasn't worth that much when we started this thing. It's something like 4,5% of all ETH supply, which is a huge vote of confidence. I mean, I'm humbled by this. It's not even doing anything yet. I mean, it's paying out rewards, but you can't get those rewards. So until we finish the job, they're not even accessible. So it's a big act of faith. Anna (00:32:09): Cool. So the change that you're talking about, the change that happened from those three phases, did that change actually happened before December, 2019? When it actually launched, was there a new version of these three phases or has the change happened after? Ben (00:32:26): Yes, it's December 2020 we started the Beacon Chain, but I think it'd been apparent for a little while that we weren't landing on good solutions in protocol for executable sharding. So how do you do cross-shard transactions? Does every movement of Ether involve a cross-shard transaction? Where is the Ether managed? It was underspecified, as I say, and better options came along, I think. And so that's what changed. So I think there'd been an awareness for a while that Phase 2, as we called it, wasn't really delivering a clear direction. So when an alternative came up, that was grasped, we ran with that. Anna (00:33:07): Around when did that happen? And what is it, what is the new alternative? Ben (00:33:10): Right. So two things happened fairly close together. First of all, Vitalik published the rollup-centric roadmap post, which I think he put on the Ethereum Magicians forum, which is interesting place for it. And rollups, as you well know, have been bubbling away for quite a while, but after we'd gone down the dead end of Plasma and emerged from that, and data availability was really understood, this vision of a base layer, that was pretty dumb, but provided lots of data availability and an ecosystem of rollups, which actually look quite like executable shards, to a great degree, it solved the problem. It meant that in protocol we don't need to solve the problem anymore, we can leave that to other people and they're much less constrained than we are, because if they go wrong, they're not going to break the whole thing. They might break their rollup, but they're not going to break the whole protocol. Whereas if we go wrong, we break the whole protocol. So that means that out of the protocol, you can do many more experiments, we're back to this evolutionary thing, you're much less constrained, you can try all sorts of wacky implementations, you can do zk stuff, you can do Optimistic stuff. And that really meant that we no longer had to deliver Phase 2, we could stop thinking about that, it's not our problem anymore. We just need to make sure that people can run rollups on this thing, and we're done. Anna (00:34:39): So is sharding still in those phases. Is that still on the roadmap? Ben (00:34:44): Yep. So to support this rollup ecosystem, we need the data availability layer. So sharding now is not executable in protocol, so you can't run sharded smart contracts and so forth in layer one, but we will be providing a huge amount of data availability. So it's 64 shards, but each shard is quite fat. I think the current estimate is about 2 MBps of data availability, which is something like 500 times more than we currently have on the Ethereum chain. Anna (00:35:17): Can I try to picture what this would actually look like? So if there's the base chain, there's the rollups that are like shards, are they like dummy shards also next to the roll-ups or is it inside the base? Ben (00:35:31): Yeah, it's inside the base. So the shards hang off the Beacon Chain. The Beacon Chain is like the conductor for the system. It sets the heartbeat, the tempo for the slots that come every 12 seconds, it coordinates the actors in the system. So you've got the committees that vote on various things and so forth. And the shards are managed by the Beacon Chain. So the Beacon Chain decides, which validators will be validating any given shard at any given time, and the shards checkpoint themselves, we call them the "cross-links" onto the Beacon Chain, so then you can construct proofs about what the shard did, what its state is at any given time. So that's in protocol, but we only have one engine, we have just one EVM in this model. And so when your rollup only needs to deal with that one EVM, that one contract environment, it doesn't have to worry about where it's running. It's just got this one interface to the whole thing. James (00:36:27): So you build the Beacon Chain, and then you build the shards that are coordinated by the Beacon Chain, and then you build the rollups that use the shards. Ben (00:36:37): Exactly. So the rollups, to be effective, to gain their speed up and be able to get the throughput, that's being speculated about need data, they're data hungry, and the data is the shards. So we end up with 500 to 1000 times more data in the sharded world than we have today. So that multiplies the effectiveness of your rollups. James (00:37:03): zk-Rollups especially are limited by how much data they can just shove onto the chain. Ben (00:37:08): Yeah. So that's a nice synergy. So we already had this data sharding phase, Phase 1 in the roadmap, and with the rollups, then these two cooperate very nicely. So you can do rollups today and then they get turbocharged when we put sharding in. So that's the synergy, that's the joy of the design. That's the rollup side of things, which killed off our execution environments, or executable shards, in protocol and simplifed things for us. The other thing that happened was this kind of backlash against proof of work. And this whole "NFTs are killing the planet" sort of thing. You know, my 17-year-old daughter gave me a big lecture about this, and I said, "I've got good news for you! I'm here to kill proof of work, this is my life's work." But this narrative, we had this EIP 1559, this threat of miners' revolts, which I don't think will come to anything or hasn't come to anything and probably never would, but it just raised the profile that miners aren't always our friends and just planted the seeds of doubt for people. And for various reasons, it just became expedient to turn off proof of work as soon as we possibly can. This is before Elon Musk started getting involved with all this kind of thing. And the momentum against proof of work is just building and building. So there's no going back now. And yet another of my colleagues, Mikhail Kalinin, came up with a proposal about a month after Vitalik did his rollup-centric roadmap, it was about October last year, which he called the "executable Beacon Chain". And it's super simple. Basically, we'd couple existing Eth1 clients with existing Eth2 clients over a very simple API between them. And we switched our proof of work and we turn on proof of stake. So now, you're, instead of being driven by the proof of work cadence, the Eth1 client, we call it "the execution engine", is driven by the Beacon Chain cadence. And he came up with a beautiful clean design for this, and we realized we could implement it very straightforwardly, there's barely any research and development to do and could deliver proof of stake very quickly. So that's the current trajectory. Anna (00:39:27): That's very exciting. Is that Phase 2 now, though? Ben (00:39:30): Yeah. We don't talk about phases anymore. James (00:39:33): I think that's really interesting, because we essentially had this huge expansion of 7 original phases, and then we progressively narrowed it to the things that are actually valuable and worth doing. And now we've moved past phases and I think where we are is we have the Beacon Chain and we just want to add shards and the Merge and that's everything that's left to do, and they're not dependent on each other. Ben (00:39:59): Right. So there is a degree of independence. We've talked about the ordering. Do we do sharding first? Do we do a proof of stake first? And in principle we could do it either way. The wins, the cultural wins, are pushing us to do proof of stake first. I felt that maybe sharding might've been a better choice. My concern is almost nobody that's been working in what we've called the Eth2 space until now has had Eth1 experience. My team's a bit of an exception, we've got a couple of devs in the team who worked on Besu, a mainnet client, for a few years. But how slowly things move within the Ethereum world, the all core devs meetings and so forth. And perhaps rightly, because it's guardian of a huge amount of value and you don't want to break anything. We've had the luxury of moving fast, without many constraints, on the Eth2 side of things. But I think we're going to hit a bit of a brick wall now, when we've done this Merge, and we can talk about mechanics and the Merge when we've brought Eth1 and Eth2 together, and things are going to slow to a crawl. So my concern was, if we don't do sharding first, it's going to take years, but we'll see. We can add it without breaking anything, I think, so we can test it separately. James (00:41:20): Speaking of all core dev calls, I do see Danny Ryan there pretty regularly and the Merge is a very frequent topic. Are you, as an Eth2 team, are you optimistic that the Merge is going to happen later this year? Ben (00:41:34): I'm optimistic it's going to happen, I don't think it's going to happen later this year. That would be nice. And I think, that meme, that thing about it happening this year is an illustration of what I just said, right? That came from a poll of Eth2 developers that Justin Drake ran, and we're all gung ho and "yeah, we move at the speed of light", but once we crash into the Ethereum 1.0 world, things move more slowly and more cautiously and quite rightly. James (00:42:02): In my experience, Peter and Martin take their responsibilities to the network extremely seriously. Ben (00:42:09): Yeah, absolutely. And it's got to be that way. And I'm getting a little bit about the caution, but it is absolutely necessary, but I think is slightly in a different world from what we've been used to. James (00:42:24): Definitely. Anna (00:42:25): So now let's dive into the Merge, because I've seen it pop up, but I haven't dug into it yet. And I'm super curious to hear what's the plan. What is the plan for this Merge that probably won't happen this year, but will happen? Ben (00:42:40): It will happen. And early next year is the expectation, read that as you will. I'm not going to put a date on it. Anna (00:42:49): Didn't Vitalik go on Lex Fridman and say this? So now it's locked in podcast history? Ben (00:42:57): Vitalik is a notorious optimist. James (00:43:00): Vitalik's also not the one on the hook for delivering the software. Ben (00:43:05): So there's work to do on what we've called the Eth2 side, up to now. So this is we're rebranding the Eth2 clients as Consensus clients. We're just running the proof of stake operation. So that's Teku, which is my client, and Prysm and Lighthouse and Nimbus. Anna (00:43:24): So are there 4 now? Ben (00:43:25): Yeah. There are 4 that are functional on the mainnet now. Lodestar are doing great work. So that's come from ChainSafe. They're writing in TypeScript and JavaScript. And I'm not sure if they plan to be a fully functional mainnet client, I doubt it, but they want to run light clients and provide a lot of infrastructure stuff, which is great, super good. So 4 currently active mainnet clients on the consensus side, proof of stake consensus side. And then you've got the cluster of Eth1 clients, which we're rebranding "execution clients". On that side, Geth obviously, Besu, which is the ConsenSys' client, and Nethermind and Erigon, I think, if that's right. Anna (00:44:11): That's the OpenEthereum rebranded once more? Or rewritten? James (00:44:14): No Erigon is Turbogeth rebranded. Anna (00:44:16): Oh, what happened to the OpenEthereum? Is that anywhere or..? Ben (00:44:21): In short, it's now being deprecated. And Gnosis has adopted Erigon and we'll be supporting that and putting resources into that, going forward. James (00:44:30): Which is unfortunate, because I would love a high-quality Rust client. Ben (00:44:34): I think Erigon is in multiple languages and is modular. And this is part of its value proposition. James (00:44:40): It is very modular. Ben (00:44:42): So we've got a work to do on both sides, but it's relatively lightweight work. So the Eth1 side will be responsible for all transaction management. So that's the execution layer. So it retains the transaction gossip, the mempools that it currently has, the discovery mechanisms that it currently has and its own networking protocol and everything remains untouched. The only thing that significantly changes is that we take out the proof of work module from that client obviously. And then we put in an API so that the execution clients will produce and will insert blocks into its block tree on demand. So now if we go over to the proof of stake sites, I'm on the Beacon Chain, I'm running Teku, for example, when it's my turn to produce a block, I get selected by the Randao process that we have to produce a block for the network. Then I will ask my attached execution node, "Give me a block" and it will hand over a block. And I will just put that block, as is, into my Beacon Chain block. And that gets gossiped on the Beacon Chain side. Anna (00:46:00): Where, I know this is going to be a bit strange, where's the EVM. Is that still back on the first version? Ben (00:46:07): Exactly. So the state management, the transaction management, the execution of transactions, all happens on the execution client, hence the name, which is the old Eth1 clients. So transitioning the nomenclature is a bit painful, because you always have people get the idea "Eth1 execution", whatever, but that stays there. So we don't need to touch that, which is the beauty of this proposal. James (00:46:35): Yeah. To make it a little more concrete, I think under this proposal, when you're running the Ethereum chain, you'll run Geth, which will manage the EVM and all the normal EVM transactions. And you will also run Teku at the same time. And Geth and Teku will coordinate between themselves to produce blocks or to validate blocks. Ben (00:46:56): Yeah, exactly right. James (00:46:58): So you're making a very strict separation between the execution, the EVM and the consensus part, which will be run by another program entirely. Ben (00:47:08): Yeah. It's very clean. And this has so many advantages. First of all, it, it retains all the work that's already been done. We're really not throwing anything away, except for the proof of work mechanism. It means that all of the application layer stuff still talks to the Eth1 execution node, as they always have. We might come to some of the challenges, but by and large, almost everything remains exactly as it always has, so minimal, if any, changes to dApps and applications and so forth Anna (00:47:40): How do the two sides of these, I know you don't want to use the term Eth1/Eth2, but I haven't picked up the new term yet, but how do they talk to each other exactly? Ben (00:47:49): So there's an RPC interface of some sort between the two, and this is going to be something we'll be talking about for a year. I just joked with McCarley, he's trying to nail down, are we doing JSON-RPC? Are we doing... What does it look like? And this is the kind of thing that devs would love to bike shed about forever. But basically it's just got a couple of end points. One is: give me a block. So the Beacon Chain says to the Eth1 node, the execution node, "Give me a block". And when it's turned to propose it. And the other one is: insert this block. So I'm a proof of stake node on the Beacon Chain, I receive a block over the network, I extract the execution part that I hand over to my attached Eth1 node, so he can insert it into his block during updated state. James (00:48:39): This is really nice, because making the separation between the execution client and the ConsenSys client means that you can swap out either side, whenever you need to. Hypothetically, when we want to add sharding, this is so much easier, because we can swap out the consensus client, because there is this strict separation between them. Ben (00:48:59): Right. And we are trying to make the interfaces as standardized as possible so that you can mix and match execution and consensus clients and so forth. So yeah, I try not to think too far into the future, what might happen. That's one way to do your head in this phase, but we're trying not to close off any options. I mean, that's, that's a big part of the goal. Anna (00:49:25): I want to go back to the rollup-centric view. What does this new scenario mean for a rollup? What is it then doing? Is it interacting with both of these? Because we talked about the two sides, the execution chain and ConsenSys chain talking to each other, but would a zk-Rollup have to talk to both? Ben (00:49:44): So the smart contract execution is all happening on the execution side. So that's on your old Eth1 client, and that's all that your rollup would need to speak to, in order to do its work. When we have sharding in place, as I mentioned, the EVM will have to be made aware of those shards and hence the rollup will have to become aware of those shards. I don't know what that looks like yet. We haven't speced that out, as far as I know. James (00:50:11): I think it's still really fuzzy for me as well. It seems like the rollup will need access to the shard data, which means there's probably some crosstalk between the two clients, again, some extension to the client interface, but I don't think we have any idea what it looks like. Ben (00:50:26): Something we're working on at the moment is light client protocols. So part of this Altair upgrade, a hard fork in the old lingo, we're doing on the Beacon Chain in a couple of months, is to put in infrastructure that makes it very easy to sync up a light client. So in a sharded world, by definition, you don't want to be following all the shards, otherwise you've gained nothing. So the idea is to make it as easy as possible to get information about what's happening on shards, that you're not directly attached to or directly following all of the activity on. So this light client protocol becomes very important. And then you gain some information, some data over the light client network. You want to prove that it is correct. So you execute a Merkle proof, based on data that the EVM has access to. And then you know that you've got the correct data. That shared out of band, but you can verify it with data that's available in band. Anna (00:51:27): Let's bring it back to the Merge itself. What will the process actually look like? Ben (00:51:31): Right. So, at the moment, stakers run an Eth2 client and an Eth1 client alongside each other. Eth1 client only provides data about the deposits that have been made. So there's only a very, very loose one-way coupling between the clients at the moment. Now, before the merge, which dates TBD early next year, stakers will need to update their clients to be Merge-compatible. And there will be a mechanism, by which, at a certain difficulty on the network, the Eth1 client will stop following proof of work. And for its very next block will follow the Beacon Chain instead. Anna (00:52:11): Is "difficulty" in this context difficulty of proof of work? Ben (00:52:14): Correct. And honestly speaking, I'm a bit hazy on the reasons for choosing difficulty, but in this context there is a good rationale for it, but I don't recall the details on that, I'll put my hand up there. But the, the idea is that we specify a network difficulty of proof of work, hashing difficulty. And at that, when that is hit, then that's a total difficulty from the beginning of the chain. James (00:52:39): Accumulated difficulty, not a target. Ben (00:52:42): Right. So when we hit that, then for the very next block, the Eth1 client doesn't listen to proof of work anymore. It listens to the Beacon Chain and the whole thing is seamless. I mean, it's beautiful. We willl drink champagne and rejoice. Anna (00:52:56): Wow. So it's almost like you upgrade out the consensus of the execution chain and then you turn on the other one. Ben (00:53:06): Yeah. So the Beacon Chain is always running, it's always there, it's doing its duty, and the proof of work will be running as well. And as the Eth1 client triggers it and just flips over from proof of work to proof of stake. At that point, it stops listening to the one, starts listening to the other. Anna (00:53:19): Will all operators have to run both nodes forever? Are they running 2 clients then at the same time? Ben (00:53:27): Yes, basically. You could probably, at this stage, get away with having them separated or having an Eth1 client serving several Eth2 nodes or something like that. However, we are very keen on data availability guarantees, and that means that Eth1 data, as well as the data that's available on the execution client, they need to be more and more tightly coupled as we go down that route. James (00:53:58): And running 2 clients may sound like a lot, but I think for anyone running a node, it's very normal. Processes talk to each other all the time, this isn't a big overhead. Ben (00:54:07): Yeah, exactly. And stakers, good stakers, stakers not like me, are already running 2 clients. I mean, I use Infura for my Eth1 data put. So that's my other dirty secret. James (00:54:19): Okay. I want to go back to the difficulty thing for a second, cause now it's a brain teaser. I think that the reason to do accumulated difficulty is because it is the thing that is least possible for a cabal of miners to influence. Ben (00:54:36): Right. And that's one of the big risks around the Merge is minor behavior at that point. In our favor, everyone knows that Ethereum is moving to proof of stake. I was aware of it five years ago and yeah, it's taken a while, but it's not controversial, we're not changing the rules. James (00:54:55): I also think that Ethereum uses miners as a boogeyman way too much. In practice, we've never seen a miner cabal impact any major chain. Ben (00:55:05): Yeah. This is fair. But I am hoping it will be smooth, but we need to take reasonable precautions against the likely scenarios or even unlikely ones that might play out. James (00:55:17): Yeah. And it's good to just select the thing that is most difficult to manipulate to just head off any possibilities. Anna (00:55:26): I think this leads us to today. We know now the plan of today. Is there anything that we can look forward to in the future? Is there anything you're looking at? I know the roadmap is very different now. There seems like there's one big, I guess there's a few upgrades and then there's one big thing, which is this Merge. But what do you see coming down the line? Ben (00:55:48): The really interesting thing about this whole thing is we've almost gone back to the Serenity plan of upgrading the Eth1 chain in place. And that's one reason why this Eth2 naming is being deprecated a bit, because it's not Eth 2.0, building a whole new chain and then throwing away the old one anymore. It's like bringing in incremental upgrades to the existing Ethereum chain. So short and mid term, we deliver the Merge. So that gets Ethereum onto proof of stake. We deliver data sharding. That's pretty well speced at the moment, implementations of that are just starting now and we're testing out the design and then there's this whole, might've seen Vitalik's massive diagram with boxes everywhere and arrows going everywhere of his mental model of Ethereum's future. And there's all sorts of things on there around bringing zero knowledge proofs in protocol to simplify many things, make ourselves a bit more future-proof post quantum, all of that kind of thing, just loads and loads of things going on. This is one of Ethereum's things, we are always innovating, and that's one of the things I really love about it, and philosophically sets us apart from certain other blockchains. But we needn't go into that. Anna (00:57:09): Are there some upgrades that have to happen on the network before all of this? Are there other things planned this year? Ben (00:57:16): Yeah. So we will do the merge likely early next year. This year we've got this Altair upgrade, which is introducing the light client protocols, so that light clients can sync up efficiently. And as we mentioned, that will be an important part of the sharded world. And we've got some accounting reforms going in there, just to lighten the load on clients and make some things more reliable and so on. We've got a couple of consensus things, some theoretical attacks have been outlined in a couple of papers, which, while exceedingly unlikely, would be nice to just deal with, so we never have to talk about it again. They will probably follow the fork choice rule changes. So we can do that at any point, we don't need to do it in a hard fork. So those things will happen this year. And then early next year, with a fair wind, we will get the Merge done. We will have a cleanup fork 2-3 months after that, we will have the famous moment where we enable withdrawals of people's stake. So you can get your rewards out and your stake, you'll be able to stop validating if you wish. And, yeah, long awaited moment. So that will just be paying back some technical debts, which we incur as a result of getting the move to proof of stake done early and then sharding. James (00:58:33): So, Ben, we we've chatted on and off for a few years. And you know, that I have a lot of opinions on the process and on Eth2. Do you have any insider perspective on all of this? I'd love to hear a bit more about all the people involved and how it all came together. Ben (00:58:49): It's a really interesting question when I reflect on gently quite a lot, because it is kind of miraculous to me. I mean, what are the ingredients that have made this, in my view, so successful. I know that everyone will agree it's usually successful. And I think there are a number of factors. The openness, we are trying as hard as we can to do everything in the open, involving client teams now funded, to a large extent, by the Ethereum Foundation, not us, but in many cases yet autonomous, on a very loose rein, has definitely helped... Made to inspect developments, broadcasting our calls that we do, doing all of that in the open. It's kind of winsome, it's attractive. People, smart people, want to get involved with this. And we see this time and time again when we've had need, people have come in. And there are people like Protolambda who just kind of threw himself into it. There's Barnaby at the Ethereum Foundation, who's really digging down into proving things about how the protocol is working. And I think smart people are attracted by this and the challenges and the freedom and the possibilities. And somehow it comes together and it's not the most beautiful or elegant, we don't have Gantt charts and deliverables and milestones, but it works. We built this Beacon Chain and delivered it. It was 2018 to 2020, 2,5 years, from nothing. I mean, it was literally a blank document and that might sound like a long time, but that's the whole R&D and protocol development, as well as the implementations and productization. And we had viable things a year before we actually went live. It took a year to do the productization and the hardening and the security audits and all of that stuff. So that's incredibly fast. I mean, compared to the old world I come from, that's amazing to me. So yeah, that's some of the wherewithal... I think Danny Ryan is a magician, he's just super uber at coordinating people and just making sure people know what they need to do, stepping back when he needs to, but stepping in when he needs to. And I think a large part of the success of the outcomes is down to him as well. I mean, what else, what else, James? What are your observations? James (01:01:18): I have an incredibly high opinion of Danny Ryan as well. I think that when he came in and started working, marks the real turnaround in this process. Ben (01:01:29): I wouldn't disagree. Anna (01:01:32): A few weeks ago Tarun was on the show, as a co-host, and made a comment around as Ethereum and these systems are more and more developed. They start to look a little bit like Polkadot. I find it very controversial that he said it, but I am curious, what you make of a statement like that? If you're seeing anything like that. Ben (01:01:52): It's an interesting observation, and I've heard it elsewhere as well. I'm not really well-versed in Polkadot these days, but from my limited understanding, there are definite similarities in the way things are emerging, with the shards coordinated by the base chain and, rather the rollups, I should say, coordinated by the EVM and so forth, parachains and so on. So it may not be an accident. I mean, for one thing, Vitalik and Gav worked together for a long time. And a lot of the ideas had their genesis back in 2014 timeframe, a lot of the early work was done then. And it also might be the case that there aren't that many ways to solve this problem. I mean, it could be that designs converge, because they are decent designs to solve the problem. But yeah, it's definitely interesting. Anna (01:02:48): Cool. All right, Ben, thank you so much for coming on the show and going on this journey with us, Ben (01:02:54): It's been a real pleasure. Thank you both. I've absolutely loved it. James (01:02:58): Thanks so much for coming. It's always a pleasure to see you. I still have fond memories of that dinner in Osaka. Ben (01:03:05): Yeah. Terrific. And I'm still trying to figure out whether you do in fact have the best hair in crypto. I'm going to ponder that one a little longer. Anna (01:03:16): Very cool. All right. Thanks again. And thanks to the podcast producer, Andrey, the podcast editor, Henrik. And to our listeners. Anna (01:03:23): Thanks for listening.