Hi, welcome to epicenter of the show which talks about the Technologies projects and people driving decentralization. And the blockchain revolution. My name is CBS anchor Jo and I'm here today with a new co-host, just as fights are who. I'm sure. Lots of you will recognize as if I know your face and the in the theorem ecosystem. Joseph. Thanks for coming on and
co-hosting. This one with me, it's actually quite fitting since we're talking with him beko who couldn't coordinates all the theorems core developer meetings and works at the, a theorem foundation on the protocol support team. And today, we're talking about, well, all things if you're re-emerge, which is quite timely because there was just a major test net, merge, right? Like a few minutes, Or we start at this, you know, this will go out fairly fairly soon after after that happens.
So this is actually quite timely. But yeah, thanks for thanks for co-hosting this one Joseph and maybe tell us a little bit about yourself and what makes you a competent co-host on this particular topic? Well if I'm going to jump in on one, I feel like this is an appropriate subject. I've been around the ethereum space for a while. I do Communications and PR work with most of my time at 3 and Foundation as well, but I'm sort
of a general tinkerer. So anything in the layer, one sort of Block Chain space, that passes the legitimacy. Sniff test is something that I've liked to play with for a while and Just happy to jump in. Cool. Well yeah happy to have you on. Hopefully you can come on for you know most of our you know, ethereum Focus episodes because I think you have a lot of Insider information and really good insights. So glad to have you here it and wonderfully about the public systems is that nobody has
Insider information. If you're paying attention Yeah, and I, yeah, Tim. Thanks for thanks for joining us today, right? Right after the merge. I'm Cipollini. Oh, welcome Unser polio yes. Yeah. Thanks for having me. Cool. So before we talk to Tim just want to tell you about his sponsors this week, security block. Chains and earning rewards needs doesn't need to be energy, intensive or complicated and by staking your That's with Horace one.
You contribute to network security and earn rewards to. Of course, one has been a Pioneer in this basement is 2018 and they secure hundreds of millions of dollars in assets on over 30 decentralized, networks including Solana Cosmos etherium and many others. If you're an institution and you want to run your own node, you can use chorus one's white label service, and their battle-proven infrastructure to participate in proof of State networks in an easy way.
So head over to course dot one and start your steak Journey were also supported by Paris. Swap are swap, is a multi-chain decks aggregator. This means that through Paris swap. You can easily access the liquidity of various different. Decentralized exchange has the protocol automatically finds the cheapest liquidity for you. So you can know that you are getting the best price for your trade Paris office. Also gasps friendly and helping
you keep your transactions low. They recently added support for Avalanche polygon, B, SC and Phantom. And you can also use Periscope directly in your Ledger Live app. If you lose use a ledger in addition to that, they are also becoming a down. So if you have USB tokens that something you can participate in. As in participate in the governance of the protocol and the Paris walked out.
Just voted the gas refund program which will allow pair swap stickers to get up to 100% of gas refunds on the trades on top of their Auto compounding yield so they're still learn more. Visit Paris, swap dot IO and since we're here I also want to mention something that I think a lot of people perhaps have already noticed some organizing a conference in Paris on July 22nd. It's called nebulae Summit. It's happening on the day after
ECC. So during ECC week which is one of the largest aetherium developer conferences in Europe, actually one of the largest blockchain developer conferences in Europe as well. Nebula Simon is all about celebrating the cosmos and interesting ecosystem so I hope to bring a lot of you know Cosmos folks and etherium folks together for this conference will be joined by Cosmos developers researchers and entrepreneurs.
As they discussed the challenges facing the interest chain and you're talking about the future of the internet of blockchains.
So take Are almost sold out as we speak right now we're going to be pulling the plug on the ticket sale soon, but you might be able to squeeze in check out nebular dot Paris for more information and I do want to mention our sponsors who are making this possible F, most anoma Club Neutron a gorik, and Celestia. So with that, let's let's get into this Tim. Tell us a little bit about your background and how you got involved in this work.
Work. Yeah well I guess your first thanks for having me on. Yeah my background so I I started like getting interested in Block, chains around 2013, 2014. First year first heard about Bitcoin and got into that. Then a couple years later, I actually heard about a theorem through the doll but when the Dow was like a project and not a hack so I'd like Her dimensions of it before. But the the doll project is really what Scotty that like actually try out a theorem.
So I literally bought ether and about thousand tokens like the week or even maybe day before it got hacked.
And and then the next morning like remember reading on Reddit the post about some I think Lisa likes a saying, I think someone is draining the Dow and that was like a pretty eventful couple weeks after that because not only was so dis big hack but after it was The term classic split and you had to figure out like how to split your tokens in order to prevent replay attacks and and I knew like absolutely nothing about blockchain stands.
I was just like copy-pasting random commands in my terminal hoping that I wouldn't just lose all my coins doing so. So it was like a really interesting, I guess what I think to get into this space but after the Dow there was like this this LOL or it felt like you know, maybe if they were was not. Going to be like a successful experiment because, well, if this is a smart contract platform and you can't write a smart contract on it without getting hacked. You know, is there, is there a
ton of value there? So I guess I could following your bit, but I didn't like late, 2016, early 2017. You start to see a bunch of projects. I use the theorem again, and obviously in, like, by mid-late 2017. There was this huge Ico, boom.
And there I kind of realize like there would probably be a lot of Man for aetherium even if like all the applications in 2017 turned out not to work clearly you know there's a lot of things you could do with blockchain like that and I decided I wanted to work like at the protocol layer because as a user like it was still pretty rough to use a theorem those days.
And you know like when there were like ico's and the mempool would say congested for like hours to days it was just like a really bad experience in felt like there's a lot, you could improve their but I wasn't like an engineer research. Sure. I was like a product manager. So it took me a while to find like a product manager job working on the protocol and not on the product, built on top of the protocol so thick like about a year.
But then consensus put together a protocol team and I joined that. And so I worked I worked as part of consensus for about two and a half years on their hybrid Edge or base you client. So got involved in basically main that protocol work through that. And as part of that, you know, I worked out with folks, like, Hudson who is chairing the awkward as calls of the time and and then around like 2020, he wanted to move on to other things. And yeah, I decided to step up
and take the role there. And so since then I've been basically coordinating these developer calls that we have on the theorem where different protocol Implement implementation teams get together and chat about it. Changes to a theorem. Yes. That's how how I ended up here. Gotcha, and before we dig into core development and sort of how governance and a CD calls, all chord F calls work in general, what your role today, we mentioned earlier, you were with serum foundation on the protocol
support side. What is protocol support? Can you just let the folks know? Yeah, so our team sucks pretty well though. That the T, my mind that the EF is called protocol support. And it's a bit of an odd team because, like, for me, it was no TV was just like Hudson, you know, like floating in the org chart and then like it since the theorem has like grown and gotten more complex in the past
couple of years. Like the basically there was just like a team put together and you know there's folks like Danny and me where we obviously Charities calls. There's a bunch of folks. To help either, like get better inputs and share updates the community, like Trent, we just have folks who work on like, you know, specific stuff behind the
scenes. Like there was the suppose we emerge today and someone on our team is just working on getting the hash rate on supposedly a so that we hit the merge at the right time. And, you know this, yeah. Stuff like client grants. Organizing like workshops. So, you know, anything that basically supports like the work of researchers and And core developers in the protocol is stuff. We try to help with yeah.
I think we're getting toward the same point but may have a little bit of a delay just so folks kind of get it. What does governance look like on aetherium how is it? How does it relate to these all chord F calls and who decides anything? Okay. Yeah, this is. There's a lot to unpack here.
So I guess like the very first bit that's important to know about like a theorem governance especially relative to like other blockchains, is we don't use like Queen voting or any sort of formal voting as part of the governance process and the roof reason there is that like we don't think that like coin holders are like the Only stakeholders that we should like disproportionately optimized for and and so if we don't have coin voting you know it becomes a much Messier process for
governance to happen. There's definitely some pros and cons to that but I think overall it's it works quite well for theorem and generally the way the way I like changes to the protocol would happen you know this is the happy path and then we can talk about all the edge cases is You know, someone comes
up with an idea. We have we have a pretty open process for like proposing changes to the protocol because all the specifications are public, you know, anyone can come and put together like a proposal to change something.
We use VIPs for that. Mostly again, there's some exceptions here but like roughly we use the IPS and so if you want to change something on the protocol you come you put together the IP and then we usually ask that you get some feedback, you know, async from people who are like have relevant. Variants in the part of the theorem you changing. So imagine, you know, you're changing gas prices or something, then you probably
reach out to some client teams. You probably want to do some benchmarking on likewise, the new gas price better if you're if you're adding something new, you know, like trying to get some feedback from like the people who will use this thing that you're adding and like why is it important to them and what's not? And once you have a proposal that's like in decent shape, we have these public calls that happen every two weeks called all core devs.
And there's a, there's a mirror version of that for for changes to the beacon chain. But you know, for now we can assume they're like, roughly the same thing. So we have these public calls people come with a proposal and then discuss it and then, you know, kind teams basically decide whether or not that this is a change to should Implement. And in practice it's incredibly rare that like a change will be
accepted like on the first. I'm the first time it's presented depending on the complexity of the change. It takes like a small number of months to like a small number of years to get that change included. And most of that time is spent just like in back and forth with protocol developers who try to understand like does this change actually benefits people and most importantly, like, is there a security risk to aetherium by introducing this change?
So there's a long list of changes that like, would be beneficial to end users with like there are settings, security issues with them. And so, you know, we can't like have them in the theorem, then, you know, assume you go through this process. You convinced everybody on the client teams of like okay, this change should go in kind of teams will typically then write, like, write the code for your
change, right? Testings and whatnot and then they just end up putting out the software there, still needs to be like, adoption of this software by the entire theorem community. And this is the part of ethereum governance, which is like, very From from a lot of projects or a lot of like uh Tyrell ones where when the client devs put out the software, you can think of it as like an opinionated suggestion,
right? Like they think like okay these are the changes we should make to a theorem and and this is when we should make them. But if people like steak yours and not operators, don't upgrade their nodes, those changes just like don't happen and then practice, you know, usually by the time we've put out like a set of changes the community
will adopt them. And the reason is like we try to prune changes that like we think would not be adopted earlier on the process just because it's quite messy to have an upgrade happen where where you know, it's highly contentious and and you know, to be carried, those have happened in the theorem in the past but generally, if something feels like, you know, there's not like broad community support and and there's not a strong enough rationale to like, Despite that then it's kind of
inclined team's best interest to not include it because then they're the ones who have to deal with like the Fallout of a messy Network upgrade. So there is definitely like this check you know by like everyone involved in ethereum about the changes that go out. And then we, you know, there's often leads to like very intractable conversations about like what is the theory of community? And who should get a say in what not then. I don't think there's like a single answer there.
You know, different change. Bring out different parts of the community with strong opinions, but yeah, it's really just process of just like trying to come up with a set of changes. That like-kind developers think will be adopted and and proposing them and and in the default case they usually end up being adopted but it's not something we can like, take for granted or forced upon people. That's interesting.
I mean, I think that's the first time I heard someone really kind of explained the the governance process for for upgrades and etherium. I spend a lot more time on the cosmos side of thing and and and of course there are. You know, there's there's there's coin voting and your governance is is an issue. I think that, you know, affects all different blockchains. Whether it's, you know, something like Bitcoin or theorem would say it with its
process. These or you know, blockchains with built-in coin voting governance. You think that coin voting governance, you know, could add some level of you useful signaling in etherium,
governance. I mean, poor governance has its flaws and we certainly see that in the cosmos faced recently, but I think that as a signaling mechanism, it's highly effective and like we saw recently, you know, some proposals on on on some Cosmos chains, like get, you know, now, Two percent or above 90 percent by in. So, I'm curious what your thoughts are here. Yeah, that's that's a good
question. So I don't think it adds much at the level of a theorem L1. And, and that's not to say it does, it's not useful in other contexts, but I think for us there's like two outcomes you can basically get with like your signal either. It's like you know mixed or it's like strongly in favor. I think for any case where it's strongly in favor we can get that signal you know quite easily. You know, and take, you know, let's take something like EIP 1559, right?
Or like that. Even the merge, right? I think if you polled coin holders about the merged, it would tell you, they're all in favor because it reduces issuance. And I you know, maybe I don't know, maybe some of them have like a vested interest in proof
of work. So they would pull against but like I my rough feeling is like, you know, it would probably be Large majority in favor and if you think something like yeah if you 1559 they would probably be even clearer because like okay coin you know, like coins are getting burnt that's like you know unnnnnnh undoubtedly good for quite holders but then it's like if we because we don't have like a formal process to gather other signals Beyond like these calls and whatnot.
It would sort of elevate. I think like that signal above others. And it's not necessarily the thing you want to Optimized for, especially in the short term,
right? Like, obviously, you know, like ether holders are like a stakeholder as part of the governance process, but they're not like the only one nor are they necessarily the most aligned, you know, you could argue like the client teams developing ethereum even though they're not like the biggest coin holders by several orders of magnitudes, like they have a desire to see like a theorems Thrive as like a long term, you know? Infrastructure that maybe like the coin holders today, don't
have right. Like maybe again if you have like a very carrot troll view of this, maybe like most of the coin holders today are just holding for the merge because that's a trade for them and like, you know, they'll move on to the next stage and I'm not saying this is the case and I doubt it would be in practice but it's like it's not clear at the me, the signal from coin holders at a specific block being much more explicit than like all the other signals, we
have actually adds value, And like the route reason there is like, yeah, you're like optimizing for many stakeholders and there's obviously some alignment between coin holders and the other ones, but it's not like complete and I think like, the more your project is like aligned with coin holders, the better like those governance votes are of a signal and if you think like imagine like a very simple hypothetical defy product, where like the coin basically gets part of like the
profits from like the upper. Shouldn't have that defy product. I think in those cases, like, it's entirely reasonable to have the coin holders.
Be like the main if not sole decider of governance there because it's like, well, they're like building this thing and this thing is like has clear like you know, business model or like flow structure funds flow of funds structure and they can optimize that and and there's not really like, you know, users are obviously maybe not quite holders but then the users are the ones who generate your Fateh.
So, like you want to keep them happy, and this is like basically, you know, pretty simple alignment problem. And whereas Fourier theorem it's like, you know, like yes, there's obviously like that ether the asset but I think that's like a subset of what like, people are trying to build
and and what users use it for. And that, you know, again the very simplest example there you could say like, well, you know it's good for coin holders when like, the fees are high and a lot of East gets burned, but that's obviously very bad for users. So you don't want the like yeah
over optimize for them. So yeah and and you know that says it's also has had coin votes in the past and I'm not sure like we've gained much information from them and this is not even getting to like the technical parts of it were like a lot of the East is not in a position where like he could
vote. So for example, you know some of it is like in a multisig, some of it, there's like wrapped in defy, some of it is like in Cold Storage so you're not even getting like a vote of like coin holders, you getting like a weird like vote of like the eith that's readily available and willing to like take some sort of like procedural risk to go and vote on that. So yeah, I'm pretty against it.
But I think for some other projects like where do you incentive alignment is just much closer with just corn holders that it makes it thundersense. We will get to the merge in just a minute. I did want to just make a one sort of point of clarification. One further question when it comes to governance digging into the stakeholders that you were
mentioning. So for a lot of folks listening in may have been a while and some of these terms consensus layer clients execution layer clients, you mentioned an entire secondary called. So, you know, in the old days all coordinates was all the Chordettes and now you kind of have these two layers happening in unison.
Can you explain a little bit about what this client ecosystem looks like and you should have your thoughts on this sort of facet of a theory of evidence and where it's headed in the years to come. Yeah yeah that's a great point. So yeah, everything we kind of talked about. It's almost like the the pre Beacon chain etherium were like, yeah. We had even then unlike other like blockchains a, theorem has many implementation teams.
So like the ethereum protocol is specified using like basically math and like some, some like readable but not optimized code and then there's different teams you like.
It versions of this protocol and I think the best analogy is like web browsers in a way where like if you go to like the, theorem dot-org on Mozilla versus Chrome versus Firefox versus fari you, you get to the same web page but obviously like Chrome versus Safari. Have a bunch of different features that's like they optimized for and so can think of a theorem client implementations as that, right? Like, where does the single specification that they follow?
Kind of like, you know, implementing HTTP and like DNS. Solving for a browser. But then there's like a bunch of degrees of freedom that they have to improve their optimization stuff around sync, speed, database storage, you know, the efficiency of API requests and whatnot. And so this means they all kind of get a say in the governance
process, right? So it's not just like a single implementation team deciding this but it's basically a set of them and to make this even more complicated in practice. Now we have both like what we call the execution layer of A theorem, which is the current proof-of-work chain where like smart contracts and and and user balances live.
But now we have this vegan chain, which is the proof of stake, implementation of aetherium, and this proof of stake, Beacon chain also has an independent specification and the set of independent implementations for it. And that means that like in practice for their governance, you know, they need to come to consensus across all these teams for changes and now we have the merge happening which is I like the combination of the current execution chain, where we remove
proof of work. And instead rely on the existing Beacon chain that the bring consensus to the network. And so this means that both from like a technical but also governance group perspective like these two layers will merge together. Where, you know, now we have people from say that Beacon chain giving input into decisions that affect the execution chain because, you know, they're affected by it and vice versa.
So and so this is probably like what the next couple years of governance for theorem are like is like finding like cleanly merging those two things and I think, you know, there's some like interesting aspects that both of them that I think we want to preserve. So I think that on the execution chain, you know, we have like this very open process.
That's like fairly well-documented and people can come into for the beacon chain because this launch like separately from etherium, they wanted optimized for Need and so, they've been like, much better at executing efficiently and the cost there is like you. It's a bit harder to like, for Outsiders to follow the process in the specific changes.
And I think, you know, as we as we Merchants to together, hopefully, we can preserve like the speeds that we've had from like developing these things independently and having it be a bit more modular but also make like the process for specifying changes across the entire theorem stack. Jack, you know, very clear and transparent.
Yeah. So that's that's the big thing will be, will be working on next, but in short, you'd say it's much more of a peer review process than it is sort of a participatory sort of token holder kind of thing. It's definitely participatory. Peer reviews a bit. It feels a bit too distanced from like, what? Compared to what we have, right? Like peer reviews. Usually like Anonymous. And like it's also usually like one or a couple rounds, like very formal and discrete sets of
reviews. I think what we have is like much more fluid where like, you get a bunch of reviews from your peers, but it's, you know, people are not Anonymous or, you know, they can be but like generally they're not or at least, not all of them. And and it's also it's not just Open to experts. This is probably the other thing as well. It's like you know for example take EIP 1559 which was like a popular one or you could think like EAP 30 74 which is like another popular change, it
hasn't made it the theorem yet. It's not just kind as like reviewing and deciding about this like the community and different parts of it. Like, smart contract, developers, and whatnot will come and they'll have strong
opinions. And those also need to get like Incorporated. So it's it's this weird mix where I guess there's a lot of public review but there's also So it's also open to like anyone to come in and, like, in practice, we get, it's like, we don't get every stakeholder that come in every time but what a change effects, like a set of stakeholders like you can, be sure that someone from that group will show up and have a strong opinion. And this is kind of what you want, right?
Like you want, like the most qualified or like the person's like the strongest opinion to be heard and and to make a decision based on that. So can you talk a little bit about the like the test net landscape and what that looks like? And what are the current test
Nets running? Yes, so that's changed a lot recently, but maybe I can like share where we were at and where we're hoping to go. But if there was like a lot of tests Nets and cousins, obviously useful for both application developers who can like deployed or contracts to
them before going to Maine that. And for client developers, who can deploy, protocol changes them before going to maintenance the problem with pestilences, like, they end up being very unstable over time because One. Like if they run on proof-of-work, like proof of work is not meant to run with like little hash rate and you get a bunch of volatility in terms of block times and whatnot at to, if they run on proof of
stake, again. It's like you're asking people to like, run these validators for no reward, so it's quite hard to keep them stable and then over time, you know, as just like a normal Block Chain their history and their state size grows. So it becomes harder to sink and node. So we've decided with the merge coming like this. Is like a good time to revisit like what are our tests and and what do we want them to be going
forward. So basically we launched a new test that for the merge called Kiln. And this is like the first one will be shutting down right after the merge. And yeah, there is just, we wanted something earlier this year that anyone could use. That was like, show them what post-merge ethereum feels like. So, both infrastructure, providers, smart contract,
developers and whatnot. I'm so it was like a new testament that we launched and It's only purpose is like you to be there as a Verge test nut before we merge the other ones. And so once we've merged my net, that one will go away.
I'm and then if you look at like the other like longer live test that we basically have Gordy Rob Stinson and rinkeby, as well as kovin, kovin has been like half deprecated for like over a year and now is like fully deprecated, because open the, theorem is basically the only software that can run validators on it. And that client, Has been in like a semi deprecated state for a year and now it's fully been
deprecated. So if you're using kovan basically this is not going to transition to the merge and so you should migrate to another test that because as soon as like the merchants the it means that the network you're using just does not does not reflect the state of ethereum network today. Rinkeby we can be is maintained by the get team and it's been around for a long time and now has like a large State and the history. Makes it harder to read notes on it.
So we're also not transitioning this one through the merge but it has like a lot of applications depending on it already. So we have a bit of a longer shutdown period where we'll probably have it be live for like about a year from now. Although as soon as the merge happens again it won't be a good copy of the theorem my net. So it's most it'll mostly be there for like Legacy reasons but in about a year should be shut down. Then we had a rough skin, which was another really old test net.
And this one was running on proof of work and it's always been really chaotic because getting proof of work hash rate on test, Nets is quite hard and and it's that means like the average amount to get is really low. But then if somebody just shows up when a minor, you know, they overwhelm the network and that causes like super quick blocks with a lot of uncles and then when they leave it causes super slow blocks. So it's just, it's just a bit
annoying to maintain. It was always quite a bit in this. This chaotic State look like a lot of re orgs. And and so we actually we transitioned this one through the merge first. Because it felt like well, you know, it's already quite chaotic. If we break it, it's probably the least bad test that the brake. And now it's running under proof of steak, but after the merge on the theorem, a net will be shutting this one down as well.
So sometime before the end of the year and this leads us to two tests Nets which were going to be maintaining. So, the first is Gordie, Gordie, is also like fairly old but I think of the like column Legacy test nuts, it's definitely the one which has, like the strongest Community around it. There's like a really diverse group of validators on it.
There's like a lot of enthusiastic running on Gordy and there's also like the biggest Beacon chain, test Nets at the Prater Beacon. Shame, that's like anchored to it. So Gordy is a testament will be maintaining going forward. We're going to run it through the merge. It'll be the last test. Now if we actually run through the merge and so that validators Like dress rehearsal that they can. They can try before before going down, may not.
But if you're using Gordy, you know, it's not, it's not going away anytime soon and then, lastly, because Roxton and rinkeby were like, so old. And like, large last fall, we launched a new test method called cipolla, and this actually just transition to proof of stake today, right? Before we recorded this and this is like a new test Network.
We're the good thing about it is it's just like super light weights to sink if you want to run a node on it you can you can get up to speed in like less than an hour and it just makes like really easy to maintain the downside is there's obviously not as much stuff already deployed there.
So there's not as much like interrupt between between contracts, but will be will be will be keeping this one as well and hopefully growing the amount of stuff on it over time and then the final difference between like guardianship olya is because Gordie already had a really like Large validator test, net. We're going to keep this as like
an open validator set. So if you just want to try stuff on your validator on the test net, you could always use Gordy and even after the merge with Prater like you'll still be able to do that. But because again, like when people have these tests and validators, they end up like not really caring for them. It causes some amount of instability on sip olya instead we've had like just a
whitelisted set of validators. R where, you know, these are all like infrastructure companies and whatnot that that commits the running them for multiple years. So there it's quite a stable experience for developers. So the recap all this Gordy and cipolla are the two tests that's that are like sticking around long term.
This is what you should be using, you're moving to, and then the other tests were going to be shutting down, you should consider kovan basically already, you know, very far down gets deprecation window and the shutdown soon, kill the merge It will be shut down right after the main net. Merge Rutherfordton will be shut down before the end of this year. And then rinkeby will probably be shut down sometime next year, but it'll be lagging behind me method. So it won't be like a great
stage environment anymore. Okay, and this leads us in a developer. It's good to know. If you're a user you've been probably waiting to hear what is the merge Where Do We Stand now? Because we're talking about test Nets and test that merges. What happened today but I will just hand you the mic for a while. What's coming up? Yeah, and I guess I think this is it's useful to give a better contact felt like, like how did we get to, like, where we are today and then like, what are
the next couple steps? But basically we've been testing the merge for over a year now. And if you count the launch of the beacon chain, it's like more like two and a half or so years. And like I mentioned earlier, you know, we launched this Beacon chain separately from the ethereum like application, proof-of-work chain, because at the time, is already a ton of
usage on a theorem. And we wanted to make sure that it's like the We can chain worked and was stable and that if it wasn't they wouldn't break everything else on the theorem. So we launched it, and after I'd been up and running for a while, you know, we started to the Prototype like, okay, how are we going to actually combine these two networks together? And like, really early designs for this?
Had like a migration as part of them, or like, users would have to move from one to the other and I just felt like, really bad user experience. We're ideally you don't want them to Have to do that. And it was this Insight in. Yeah, a few years ago that well, the clients, that run a, theorem, the proof of work chain today. They're already used to this concept of like different
consensus algorithms. So, like we mentioned, you know, main that mean that uses uses proof of work but a lot of the test that's don't write. They use what we call proof of authority, you're just different consensus engines and similarly like a lot of Enterprise private networks. Also, Use like different consensus engines. And so there is this idea of like, well what if instead of moving all the applications over from like the proof-of-work tank
to the beacon chain? We simply had like the software that's running all the applications change, what consensus algorithm it listens to you to get, like to get the consensus on the state of the network.
And this is like that, the very high level design of the merge is that once we hit a certain point, the clients on the network, stop listening to proof of Work as a way to get the latest valid head for the for the blockchain and it started listening to the proof of stake Beacon chain and this means that you don't need to move all the applications over from one to
the other. You can simply kind of use a different rule to tell you what was the latest Allan Block and keep kind of building on the existing existing chain. So we first prototype that in May of last year, there was like a hackathon and we got some of the client team.
To get her to prototype. Like, could the post-merge architecture work, where you have a beacon chain clients, that kind of keeps track of the head and then they receive blocks and they send them down to their execution client, which runs the evm transactions. Make sure that those transactions are valid and then like confirms that or orphans the block, if not. So we prototype that in this
hackathon, we got it to work. So that was like, good confirmation that like, this design was sound, you know, like with the What would the two clients talking to each other? Obviously it was a hackathon for a ton of bugs as we spent like last summer, fixing all those bugs and ironing out a design for like it, final architecture. And then last fall we prototyped the actual transition from like proof of work that proof of
stake. So could you like start a network up on proof-of-work, started Beacon, Shane separately, and have them transition and you do not fall apart throughout and safely like finalized on the other side. So we got everyone in person actually for this for a week and after like a week of work we managed to get like a first prototype of that working where we launched a definite and it started on proof-of-work moved over to proof of stake and it's
finalized on the other side. And so again, this was just like a week-long hackathon. So there were tons of bugs and issues, and we spent like all of the Fall after that fixing those. And by they see the Christmas holidays. We How to spec for, like the entire merge and post-merger Theorem, which we felt was like, pretty stable, like not perfect but, you know, roughly, right? So we launched. Its first test, is called can Sugi, right? Like late, December.
And this was just like, give people an idea of like what post-merge etherium would look like for us to reach out the infrastructure providers and application developers to make sure that like, you know, things didn't break when they were using it then, and And we got that confirmation. We also run a bunch of stress tests on the network like spammed it and put nodes and weird States and we found doing that. We found some, some edge cases
in this spec. So we fixed all of those and in March, we launched this killed test net, which I mentioned earlier which which was basically like call it like 95% final spec for the merge. So we've done some small tweaks to this text since then, but no like big substantive changes. They've mostly been either like clarifications or just, you know, some edge cases that like a subset of clients were hitting and whatnot, but like, the overall like functionality has
stayed the same since then. And after after launching Kiln, we still felt like it would be good to get like some more practice runs because you learn a lot. Like, when the network runs through the merge and it's a bit weird in a way because this is code that only has to run once on Main meth. And there's like a ton of complexity there. But in one summer just happened, you know, you never need to run through the transition again.
So we wanted to make sure we got like as many kind of runs of that as possible. And we started doing these things called Shadow Forks, which are basically hard Forks where we only launched a small number of nodes, controlled by my client and testing teams which which have the hard fork and then we see how it goes for them. So you can think of this like, you know, there's like thousands of nodes on like the theorem Network.
Well, we take like, 10 to 100, we spin them up and we tell those like small number of nodes, I hate emerges happening here and then we actually run through the merge on those nodes and see what happens. And, and for a couple days, also, we can replace transactions from Main methods. Well, so we get to see, not only like running through the merge on maintenance but also our denotes table afterwards, you know, can you still sink and whatnot.
So we've been doing these shadow Forks over and over. I think we had like our 11th or 12th one. Earlier this week. So basically, like every week since since like late March, if not multiple times a week sometimes, and that's been really good that help us test like not only every client implementation but also every pair wise combination. So earlier we mentioned, you know, there's like these clients that work on the execution chain, these crimes. That work on the beacon chain,
there's four on one side. Five on the other this means there's like, 20 pairwise combinations of like, one Beacon. Then what, execution time that you can get. And so the shadow Forks we basically passed every single possible permutation and we want to make sure that they all work and then we find, you know, when we find bugs we obviously fix them.
And this is roughly like we're, we were like a month or two ago and now we've, you know, we feel like much more confident than liked it. The the Readiness of the code we're not like 100% there yet, but you know, we felt ready enough that it made sense to start. Working the like long-lived tests on a theorem and there were a couple of reasons for that. The first is like, which Rob's then we mentioned earlier. Like it's quite a chaotic test, it's already.
So it was even if like something went wrong. It wasn't the end of the world, but we also wanted to give end users, like people running validators at home, the chance to run through like emerge. Basically because all these shadow Forks, the nodes are basically controlled by client teams and testing teams. But it's not open to anyone to run a node. So we have this first Roxton Fork where we had, we had like a new Pekin chain launch for Rustin and anyone could join that.
And yeah, I'm on that. You know, we had people for this faith and the network moved over and generally the transition went well. So that was good. We found some couple bugs that's been fixed and then today we ran through the second test and that's that polio and the goal there was to make sure it was like the bugs, you know, the bugs on Robson wouldn't show up again and we're still worse.
You generally looks like the fork went well but we're still digging into the details and coming through everything. Once we have that we basically have one more test net to do before May Nets and this is gorney with the printer Beacon chain and this is a test Network.
You know, we really want things to be quite ready because this is where the majority of stagers are like expected to like run through the transition with their set up in anticipation of maenette and it has a ton of activity as well. So it's not a test that we wanted to. The break. So once, you know, we once we've like, debriefed on this supposedly a fork and and see whether there's any issues we need to fix or address. What we'll start scheduling and Gordy and then ones Gordy
happens. Assuming it goes well then we would look at scheduling the fork for magnet and the goal is really just to get as many like dry runs. As we can in the increasingly complex scenarios where if you start super complex room to slide from the start, you're
going to hit Bunch of issues. It could be really hard to find a root cause but if you start with like the small Dev Nets that you like increased complexity over and over, you always liked fixing bugs at like the edge of like the complexity and it just makes it much harder to much easier, sorry to fix those bugs. If you're, if you're increasing complexity as you go. Yeah, in short. It's like, yeah, we spent the past year testing, we've done
one more test net. Today, there's one left and assuming things go, well, go. Well on that one. We'd move to my nut. So to recap, that merge specific, Dev Nets, long-standing merge specific Testaments in line with these shadow Forks, upgrade, the long-standing ethereum test Nets that we covered earlier. And then maenette, with one more long-standing test, net left to go, and that's girly. That's correct.
Yep. And then Gordy with the Prater Beacon chain and we'll just call it all Gordy after it emerged. So what do you look for in a successful merge and when it's done what's next? So, I know that a lot of work has been done on Shanghai, and a lot of those listening would probably be curious about. So there's some misconceptions about the merge and I'm sure you're probably very familiar with and can speak to from token on blocks to scalability.
And some of those things are covered in the next sort of set of upgrades that come after So what's left coming up until the merge? And what comes next? Coming up until the merge is basically we want to monitor these tests Nets like not only right after but also like you know call it a week after so that we can still sink notes to
them and things work work well. And you know we have a whole slew of metrics that we look at like from some pretty basic stuff like our blocks being produced to like you know are like transaction fees for every transaction being routed to the right way. So it's you know now let's read just combing through all these metrics and making sure that like things are looking good and fixing anything.
Or it isn't. And then when we fix things, you know, if we find a bug, well, typically, then write a test for it and then run all the clients through this test Suite, because it's possible that it's just like, you know, one client, it's something during during emerge, but then all the clients actually had the bug, it just happened, not to hit it.
And so that it's like, it's really like fine calming through that and then if you know if you look out and you assume the virgin's happen and we're all good. Yeah. There's obviously more things on the etheric realm. But beyond that, and maybe the first that you hinted at, is this idea of like Beacon Cheng withdrawals. So because the merge is like the most complicated upgrade we've done to a theorem since probably
launching a theorem. We tried to cut down anything that wasn't absolutely critical from it just so we can have like the smallest possible set of changes which is already a pretty big set of changes and and and the the the biggest like cut that is the ability for validators. Withdraw their Stakes back to to the execution layer. So the like Foley exit as a validator. So that's like the first big feature.
We're planning for after the merge typically, when we have these hard forks with, with new features will introduce more than one. So there's a bunch of other proposals as well, but that's the stuff will be. It will be working on right after one thing. I'll note though with regards to validators and withdrawals is while validators, won't be able to withdraw like they're their Stakes after the merge like the 32. Heath + like the rewards they've accrued as soon as the merge
happens. Validators will receive transaction fees that currently go to minors and they'll be receiving that on the execution layer itself. So they won't, they won't be locked. Like, validators are on the Deacon. Shame. So this is kind of neat. So if you are a sticker or even like using your stinking pool or something, you will start accruing.
The non bird part of transaction fees, right after the merge. so let's talk about what happened, just just a couple of minutes ago, but an hour ago, the the cipolla emerge can you can you talk about that and in the context of like sort of a you know, this this broader roadmap and how significant it is to the broader merge efforts Yeah. So like we were saying, it's like the second out of three tests nuts and it is like this new one, which we hope to keep stable and the, the validators
on this network are like a set of, you know, climb teams testing teams, infrastructure providers. So it's not, it's not like quite anyone like we because we want we want this network to be stable. We basically opened it the like any individual or entity that
can come. It's the running state Validators over a long period of time but it is not just like a web page where you can sign up and launch a validator like there is for Prater. So this was like a good test because it's like it shows us. Okay. Like there is still like some group of like this think entities and individuals that need to coordinate and and debug things but it's still not as open as like the the Prater you can chain or maintenance. So yeah.
It's like it increases like the complexity of things. You know, because we're on this, this this call. I haven't liked the digging through all the the specific things that happen but a lot of high-level right before I jumped on it seem like you know the network was relatively stable, there were some parts of validators that's hit like some some issues or were offline and it seems like folks are still looking into that but well, no better than like the next couple
days. Like, you know what types of bugs that we hit, where they boarded bugs. Were they actually just like, And issues. So, if their configuration issues is actually quite good because it's like, you know, called is like operator error rather than the like protocol problems. So that seat, you can just restart the validators, the wrong with the right configs, and it works. So that's what we're looking at. I think once we have a clear picture, there will start thinking about.
Okay, when do we want to Fork this last test net? I think our bar for the last test, net will be higher because we want to make sure that like, any Staker can run through it. And that it's Like as close to my net as as possible. And then yeah, assuming that goes well then we would we would then move to merge magnet. And so this next test net, anybody, anybody would be able to run a validator on this on this on the next Testament. Yeah.
Yeah and you can already right like so you don't need to wait for the Verge. You can literally go and like register validator on Prater and and have it the up and ready for the merge. And if if you want to also run a post-merge validator right now, you can do so on rough stdin. So rough said has merged and so you won't run through the actual
transition. But if you want to figure out, okay, how do I configure my validator so that like I actually get transaction fees and like, And some validators. For example. Today, it is possible to use a third-party provider. Instead of running an execution there node to track deposits. After the merge, it won't be possible to do so. So if you've been using, say in for our Alchemy, but your beacon chain, clients to track deposits. You can't do that after the
merge. So you need to figure out, okay, how do I run? You know base, you never mind, get Aragon and you can do all that on Roxton today and register a validator and make sure that it's working. Yeah. Cool. So as we wrap up here, I think it would be interesting to maybe talk a little bit about about scaling and you know how like how post-merge, what's Caitlin we look like post-merge?
And you know I think it's interesting that you know a theorem is taking this data, availability approach and allowing sort of like ecosystem change to build on top of this on. This on top of this base layer, what is what is your view about? Like what this ecosystem will look like post-merge you know, where will cover the majority of applications live. And, and I think one interesting, one interesting thing maybe also to consider is what are some of the interoperability.
I mean beyond the, unlike bridging instance, things like that. Like are what is the word, the the work being done on a Need to ensure that all these different Roll-Ups and like chains built on top of the data. Availability layer will be able to talk to each other and like do cross chain calls and stuff like that.
I think you know, over time in terms of just like designing if they them there's been this this like Evolution where it's like if you compare a theorem when it launched a Bitcoin, it was like this maximally complex blockchain relative to fit quite right where you know it concerns itself with like arbitrary computation and state and whatnot.
I think obviously the blockchains landscape has evolved a ton since them and and like the kind of design See in a way for theorem has has kind of shifted the like okay what is the actual minimal set of things? We can provide with the highest level of security, which dead enable people to build, you know, applications scaling Solutions and whatnot that depend on them.
And so, you know, like one very obvious shift is I decided that ethereum originally wanted to do something called execution charting where there's a bunch of like L1 shards which each process comp A patient and parallel that are like management protocol. And we've moved to this world where well instead, we'd rather allow like a free market of like solutions to emerge and use etherium as like more of a settlement layer in this would be seen with with l2's today.
And this is how, you know, we think about like scaling is the l 1 chain. Like, I mean the capacity will keep improving and there's some stuff we can do but like it will not improve as quickly. As like the demand for Block space grows, you know, so if you imagine we improve the capacity like 10x or 100x over to next like five ten years, the men for blockchain might grow like 100,000 x, right? Like we need like several orders of magnitude more and this is where things like basically layer.
Choose can't provide that. And so, and the way layer 2's work, like, at a very high level, is that they trade off this asymmetry, we're on etherium. It's like very expensive to run computation, but fairly cheap to store data, whereas on an L2 is actually quite cheap to run
computations. So if you can run all your computations on L2 and post like some data about them back to L1 that allows you to, like, lower your fees a ton because you're just running all these computations and not actually running much on a theorem L1 +, ZK, Roll-Ups and optimistic, Roll-Ups differ and how like, They approach this but a high level it's like this is a symmetry between the cost of like running operations versus posting data.
And so if we could get scaling solutions, that just run those, computations off chain, either, like run like some proofs on chain or some some disputes on chain but in mostly post data that allows like for way cheaper transaction fees and for more scale. And so today when these these Roll-Ups and scaly institutions pose that about to aetherium, the only mechanism they have to do so So is like storing data in the blockchain forever. And this has like two to
consequences. One is like every single note on the chain needs to process that data and to the, the hold on to it basically forever. And so that means that like it's it's still fairly expensive to store data on a theorem and so when you pay for like a transaction on a layer to most of the cost, you actually paying is to store this data back on the theorem. The first thing we could do there is like, okay, well how do we make it cheaper?
For data on other theory of because that doesn't mean it's like cheaper for all these Roll-Ups that could be built and or conversely that they can, like, accommodate more demand for the same price and therefore scale. And one thing about the Roll-Ups is, they don't actually need this data to be stored Forever on the network. They only needed to be posted on the network and available for like some amount of time such that people can like, agree that it was there and then it was correct.
And if If it is not correct have like a reasonable amount of time to dispute it and typically this is on the order of like a week more or less. So there's this like exception within Roll-Ups that like, if the data has been made available for roughly a week, it gives time for people to like, sanity check it, make sure that there's no, like either malicious or buggy transactions, or like mismatch between what the hell. Two things is the state of the world and what L1 thinks the LT
state of the world? Is and if that happens that it's fine. And so this is really the window where like you want to provide like really strong security guarantees around this data, this short period of time and after that you almost like don't really need to provide much because you can assume that all if there was a dispute it would have been resolved. And and if somebody wanted to make a copy of the data that they could have done so already.
And so this is where we get it to like this idea of data availability. Which is say like, what if If instead of just having these l2's store data on the blockchain forever, they simply post it to another place where still secured by etherium, but we don't guarantee this data is available forever. We guarantee it's available roughly like for how long roll ups. Need it with some buffer, you know, on each side.
So like I was saying, you know, Roll-Ups usually need to stay left for the order of like a week and like the proposals for theorem right now is like what if we just provided a way to make data available for like the order of like a month? Or something. So it's like, you know, even if it's even if you needed within a week, yeah, like maybe you need
to sink a node. Literally, you know, you need to go buy a computer, get an internet connection setup, get the guy come to your house, set it up, stick your node and and you know this extra buffer would give you enough time that like you could still recuperate student data that's way. And so this is when we talk about like Proto, thanks Char. Take. This is roughly. The idea is what if we added like just a daily component on the theorem, which is like affair?
Emeril but still highly secure but then you can charge less for this data component because you're not, you're not basically incurring a forever storage cause you incurring like a short, duration, storage cost, and then the next level beyond that is, what if instead of having all the nodes on the network in cure this like short-term storage costs, you could scale the amount of data that you're storing have nodes Only Store subset of it but then get like a really Hi,
probabilistic guarantee that the rest of the data is available on the network. And this is like, when we talk about like full sharding, fourth area, more like, dang sharding, which is like the latest spec for it, this is what it means. Is we take this this infrastructure that we have the store, like it ephemeral amount of data.
But instead of having every node store, a full copy of all the data, you have every node Source a subset of it and do some like cryptographic checks, Across the peer-to-peer Network to ensure that other nodes are storing the rest of the day. That would like a really, really high probabilities. Right? Like thank you though.
There's like I don't know if it's like in the billions or trillions but like there's an incredibly low chance of like some amount of data would be would be unavailable on the network and because basically, by doing that, you're able to scale roughly by another order of magnitude, the amount of data that you have. And then those, those cost savings or like, basically, K-league bandwidth gets passed on for layer choose and other solutions that help.
And so this is like roughly. The vision is just like, can we hone in on the parts where security matter to most and like put all of our efforts there and provide like these incredibly high like security assurances that this data, you know, was made available that this data was like correct and that the network came to consensus on it. But then after that kind of Outsource the, like, the community into the ecosystem, like ways to store manage that data.
And you know, you're at a point was around like, like crossed, you know, L to Communications and stuff like that. I think, again, that's something where it feels like the L1 protocol itself is not the place for that to live, but where it's probably much healthier. If you see just like Market, the merge and the best Solutions, you know, gain traction there. Okay, so, to recap slightly, the merge is happening.
And then, after the merge happens, we would dig into things that look like optimizations that help with scaling in L2 land. But I think, you know, as we come close to closing, I could give you the mic back to talk a little bit about why. I think some folks may be fell off the wagon a little bit. Is that as a Research changes titles, change, naming schemes change, and roadmaps change.
So, for those that have maybe been on the epicenter train for closer to a decade, there are four stages to ethereum is roadmap, right? There's Frontier Homestead, metropolis and serenity and that's long gone. And for those that sort of came around during the Ico era. The question is when T2, which still kind of exists today in a couple of different places and people that can Use one another with supposed token. Name changes that don't exist, but this revolves around some phases.
So, would you say this is kind of where the road map stands. Now it's a merge be these kind of optimizations and whatever else into the future. What is today's is this sort of today's ethereum roadmap I guess I kind of met apart from your question is like clearly the theorem roadmap has changed a lot, so it's it's probably naive to expect, you know, today is when it gets set in stone. I think maybe like the biggest like conceptual changes were a bit less, like a linear now than
we were before. And because we've grown the amount of people who contribute to the protocol, we're able to do stuff in parallel to it agreed like We couldn't and so there's things like when you know, like if you looked at like you know, this like Frontier at the serenity roadmap or like eats two phase zero phase one phase two, they all assume like, you know, it's like we're going to work on 8 and we're going to
work on video. We're going to work on C. Whereas today it, I think we're in a spot where like, obviously we need to ship things. One after the other, we can't ship every single thing at the same time, but there's definitely different teams and different like, even within teams like people that are working. Going on, like the various, you know, big eater issues with ethereum or like areas of improvements and the kind of
happening in parallel. So like we talked about like we talked about Beacon, Cheng withdrawals, we talked about sharding. We talked, you know, we didn't talk about like, Mev and proposer Builder, separation that we didn't talk about like statelessness and we didn't talk about like DVM and genuine to improve that, but those are all like threads that are happening in parallel today.
And I think you know a lot of high-level it's like there's some protocol related things that we need to do to ensure that a theorem like scales and is safe and like and that we we don't end up in like a spot where there's like some centralized actor within the system who can like exert a really high level of control and of influence and there's a ton of work that's being done on those fronts. But then yeah, there's also a ton of work that's being done.
Like, Making sure the evm stays like relevant and keeps improving and luckily, it's like, they're not blocked on one, one on the other. And what what, I think like happens is, then, you know, whenever something goes from the spot where it's like ready to go from research to Productions, then we typically will prioritize that and and gets working on it at the client level.
And we've been lucky so far that like, it's just not happened as To R&D efforts are like ready to shift at the same time and if they are in the future which it probably will happen, then we'd have to decide which one is higher priority or do we want to bundle them together but yeah I think it's yeah there's not as much like a single big roadmap and and that's one thing we've tried to do like with the naming. You know, you talked about like a 2 versus eat one and today we
call them like the consensus. They are versus like execution layer and I think the best naming strategy like going forward is just to try and Like describe things like very like plainly like what they are like, you know, the consensus layer like helps you, theorem Network. Come to consensus on the valid tip of the chain, the execution layer, actually runs those
transactions. I think once we have like sharding live, you know, it would be fair to called out like a data layer or like a data availability layer. And and similarly if you look, you know, the Mev land, when they start to think about like proposer Builder, separation, it's like they're taking this one step further. They're looking at, like, okay, what's the role of a validator where the different tasks that like a validator can do?
What are the degrees of freedom? And can we just like, you know, segment that in an even more granular detail so that we can we can analyze it better. So that's my hope. Like I think if we if we can go for like having this like very vague like yeah. Terms to just saying like Okay these are like the five biggest problems and we need to address them and this is like the solution bit that's Going to address them, I'll be really happy.
Obviously, it's off its off my cultivate, but I've appreciated that we're trending in that direction. And I think we're going to have to save proposer Builder to reparation for the second round. Yeah, you did someone else to come and give it to our talk on that? Yeah. Yeah, the next, the next time we have someone from from EF on, it'll be the answer.
The question when III we should, you know, we need to start getting some content out like early about about III again since, you know, since it's our history with, you know, covering this sort of topic on epicenter. But yeah, thanks, thanks for coming on Tim. It's been great and you know hopefully now our listeners, get a much better view of the overall. All arch of the merge and everything. That's, that's coming up. Next, certainly I have a much better understanding NASA.
Hopefully, we can get you on again soon and in a couple of months, when when things start to move into production. Also, if you have, thank you so much for having me. Great, thanks. Thank you for joining us on this week's episode. We release new episodes every week. You can find And subscribe to the show on iTunes Spotify, YouTube SoundCloud or wherever you listen to podcast. And if you have a Google home or Alexa device, you can tell it to listen to the latest episode of
the epicenter podcast, go to epicenter, .t V /, subscribe for a full list of places where you can watch and listen, while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If you want to interact with us guests or other podcast listeners, you can follow Oh us on Twitter and please leave us a
review on iTunes. It helps me behind the show and we're always happy to read them with thanks so much and we look forward to being back next week.