 at Chainsafe Systems. Thank you. I'm also one of the co-organizers of East Berlin and I used to work on various EF and ESP grants in the past for both execution layer and consensus layer clients. And among others, as Franzi already mentioned, I launched the Grally Testnet with a bunch of cool people that are also sitting here in the room in 2019. So what I'm going to cover today is I want to briefly dive into the Ethereum protocol history prior to the merge. And then specifically take a close look at the implications of the merge on the testnets and finally give a quick guide to selecting the testnet for your project. So yeah, let's dive right into the protocol history. Everything started with the testnet. Does anyone here know what's the meaning of the Ethereum Genesys extra data is? You might know the Bitcoin extra data Genesys extra data contains a news headline. Does anyone know what the meaning of the Ethereum extra data is? It's actually a block hash from a testnet. Ethereum was publicly fairly launched by announcing a block number on an Olympic testnet that was 1,028,201. And once this testnet was mined on the test, once this block was mined on the testnet, this hash could be inserted into the Ethereum Genesys and the public mining on the Ethereum mainnet could start. Olympic was the last pre-release testnet before the Ethereum mainnet was launched and the first public Ethereum testnet after the launch was Morden. Morden was a proof of work testnet using the same e-shash algorithm as mainnet and interestingly it had a custom starting launch of 2 to the power of 20 to prevent transaction replays on mainnet. Most of us probably remember the Shanghai attacks during DEF CON 2 in 2016. An attacker exploited the long discrete time of the Xcode size opcode in one of the client implementations which caused the denial of service of the Ethereum mainnet. Here's a photo of the amazing guest team investigating the issues and coming up with the solution. To address this issue two subsequent hard forks were scheduled for Ethereum. The Tanguin whistle fork to fix the attack vector and the spurious dragon forked to allow cleaning up the state afterwards. However, this protocol change caused a consensus failure on Morden. This was specifically caused by the different ways how the clients handled this custom starting launch and it was then decided it's not a good idea to have a custom protocol on the testnet and therefore Morden was discontinued and replaced by a new testnet called Roopsten. Roopsten was the first testnet to launch with ShineID right from Genesis. The ShineID served the purpose of simple replay protection according to EIP 155. So the Roopsten testnet was also powered by the e-shash proof of work engine. We all know proof of work is fairly permissionless so there is no good incentive to secure a zero value proof of work testnet. So attackers moved to DOS Roopsten and the testnet was unusable for weeks. In response, parity launched the Coven proof of authority testnet and guests launched the Ring B proof of authority testnet. For the first time Ethereum had a way to have a more stable testnet environment. However, Coven used the Parity Aura consensus engine and Ring B used the guest click consensus engine and they were not compatible. Coven was therefore only accessible through the parity Ethereum stack whereas Ring B was only accessible by guests or tooling that relied on the guest stack. So in 2018 the girly initiative attempted to address this by ideating a cross client proof of authority testnet. In the end, the initiative managed to implement click and parity and subsequently in 2019 the girly testnet was launched as a first cross client proof of authority testnet with validators from both guests and parity Ethereum. At the same time, coincidentally, after DevCon and Prague, I believe, the Pantheon client was released. So there was even a third client available for running validators on this testnet and soon after also Nesamind joined the validator set. Yeah, later this same year parity exits Ethereum and leaving Coven fairly unmaintained. Unfortunately, now going fast forward in time, just earlier this year to prepare for the merge, some of the older testnets had to be deprecated. The protocol support team announced the end of life for Rupsten and Ring B on the amazing Ethereum foundation block. They argued the older testnets are harder to maintain due to growing history and state and to growing complexity to run the testnet setup. So in foresight, however, a new testnet was launched, Cipolia. Interestingly, Cipolia that was just launched not even a year ago, it was launched as a proof of work testnet using the same ESH algorithm as mainnet back in the day. It was the first time since the Rupsten launch in 2017 that we actually launched a new proof of work testnet. The reason was potentially to have another testnet similar to mainnet to allow for once again testing the merge and now mainnet conditions. Okay, so let's recap the testnets prior to the merge. Morden is fairly dead. It was replaced by Rupsten in 2017. Rupsten then again was just deprecated a couple of weeks ago. Coven died with parity leaving Ethereum. Ring B was also deprecated just a couple of months ago and that leaves us with Curly and Cipolia as the latest testnets for Ethereum. And now let's just take a look at what it actually means to merge. I took a lot of time to build these slides. So in Ethereum, the merge stands for an event where two blockchains are literally glued together. You need a consensus layer beacon chain that takes over finality and fork choice considerations here shown in blue. And this consensus layer beacon chain replaces the legacy proof of work consensus or other consensus mechanisms on the execution layer here depicted in red. So the slide shows the timeline of the testnet merges and I added a lot of details here. I'm standing in front of it. I added a lot of details here but let's revisit the slide in a bit after talking a bit about implications. So just to recap, the proof of work consensus mechanism is permissionless as per Nakamoto consensus. So you can just turn on your CPU miner and hope for a block in theory. On the other hand, proof of authority is permissioned. Obviously, only authorized accounts may take part in consensus. And then again, proof of stake is fairly permissionless. You have this token and you can stake it to take part in consensus. So what does it mean for Ethereum mainnet to merge? Obviously, moving from proof of work to proof of stake just does not change much in this perspective. It was permissionless before the merge. It was still permissionless after the merge. But how does it look like for the testnets? So Gurly was merged with the Prata beacon chain testnet and to get access to the consensus on the Gurly testnet prior to the merge was permissioned. So Gurly was running community maintained value data set. However, after the merge, it transitioned to a proof of stake consensus. Interestingly and suddenly, everyone can participate in consensus given you have access to Gurly. So Gurly used to be permissioned. It's now permissionless. But what about Zipolia? As I mentioned, prior to the merge, it was powered by the permissionless ESEH, a proof of work algorithm. You can see my Zipolia miner. I was happy that I once again can mine a testnet. And yeah, I did not ask for permission. I was just able to mine the blocks. I got a lot of Zipolia either. But now there's something unique about the Zipolia beacon chain. Since it was apparent that Gurly will no longer be permissioned, there was actually the quest for having another permissioned testnet to have certain stability guarantees. So it was decided that Zipolia gets a beacon chain with a modified deposit contract that does not accept regular ESEH deposits. Instead, it tracks the validator set through an ESEH 20 token. So in that case, Zipolia is a proof of authority version of the beacon chain, and therefore access to Zipolia consensus is permissioned. So let's take a look at this overview again. This is a timeline actually on the X axis. The first testnet to merge was Rupsten. Rupsten was fairly similar to Mainnet. It was proof of work. And after the merge, it was proof of stake, right? So permission less, permission less. Then Zipolia transitioned with this modified beacon chain. So technically, the consensus algorithm is still proof of stake, but through this permissioned ESEH 20 token that you require to take part in consensus, I call it for simplicity proof of authority here because the access to this consensus is actually permissioned. And then, girly merged with Prata and testnet were exactly the opposite happened. The proof of authority girly testnet became a proof of stake girly testnet after the merge. And then, yeah, we are here. Eventually, just a couple of weeks ago, the Mainnet merge occurred. So yeah, just take a look at the post merge testnet landscape. I showed you that Rupsten merged. However, it has been deprecated by the ESEHM Foundation's protocol support team. And it leaves us with girly and Zipolia as the only longstanding public post merge testnets. So I will conclude my presentation with a testnet selection guide. I mean, it's only two testnets. How hard can it be? I mentioned how amazing the ESEHM block is. It's just a great resource. I found this slide on the ESEHM block. Basically, just recaps what I just said. The open validator set for girly, on the one hand, the closed validator set for Zipolia, on the other hand. Obviously, since girly is much older, it has a large state that gives some better network effects. So if you have an application that you want to deploy on girly and you require other applications or interfaces, you might find them on Zipolia, on girly, but not on Zipolia, because Zipolia is fairly new and not many applications on libraries are deployed yet. However, it's also longer to sync and more involved to run girly infrastructure. So to summarize this, please do use girly testnet as it is most similar to the ESEHM mainnet. Girly is especially interesting for you if you plan to test a beacon chain validator. If you want to test your setup, if you want to test upgrading client versions, if you want to test going through protocol upgrades, girly is potentially the best or if not even the only testnet where you can actually conduct this. Yes, please also do use Zipolia testnet. Zipolia comes with the best stability guarantees due to the permissioned validator set. Since it's fairly new, it is fastest to sync and also it has the best long-term guarantees. So I would lean towards recommending to test your applications or even migrate your applications to Zipolia instead of girly at this point. Yes, do not use Rubsten, obviously. When I prepared my slides, I realized that we are just in this transition phase where big service providers already start shutting down infrastructure, so you have to expect interruptions and downtime. Don't use Coven for obvious reasons. And yes, also I would not recommend using WinkBee even though there is some long-term support planned for WinkBee for almost another year, but you will potentially not get more protocol upgrades on that network, so I would also not recommend using WinkBee in that regard. Yeah, right. There are some caveats, so as I mentioned, the girly testnet has ESA supply issues due to the sheer amount of users trying to test their validator setup. Each validator requires 32 ESA, and if you want to have a more involved setup with, I don't know, 1,000 validators, it quickly becomes a huge problem to access these required testnet tokens. This is something we still need to figure out going forward, so if you have an idea, please hit me up. Yeah, and in terms of testnet age, girly is also fairly old, so it comes with a fairly big, rich history in state, and is therefore more difficult to synchronize, especially now that it's merged with Prata, which also comes with a fairly old beacon chain in combination. And yes, Zipolier is relatively new, as I mentioned. I wrote down lack of infrastructure. I put it in brackets because it's changing really rapidly right now. I just noticed while preparing my slides that even MetaMask has a Zipolier testnet switch now, so it's happening. I'm really happy that we get all these integrations now. But yeah. Okay. This is my subjective recommendation. If you want to test infrastructure, if you want to test your validators, I would recommend you to run them on girly. If you want to test your applications, I would even encourage you to skip girly and go straight to run your stack on Zipolier. Okay. This was my talk. Please use girly or Zipolier going forward. Find me for some spare ESA cards from East Berlin. They are preloaded with girly and Zipolier ESA, so if you want some, I will not throw them into the audience, but just find me after the talk. And yes, since we have a couple of minutes left, please ask questions. Thanks for the presentation. Is there any tutorial or manual how to be a validator in Zipolier, how to be, to help in infrastructure? Short answer as you can't, because as I mentioned, even though it's proof of stake, you need a special ERC-20 token to get access to this validator set, and you would basically have to Google Zipolier GitHub repository, and there is an issue where you can request to be added to this validator set, but in general, not many teams will be accepted just to keep it really small, the validator set. Maybe two questions here. One, when EIP 1559 came around, it was very hard to test that in advance, because you have these proof of authority networks that had no fee market, and then you have these proof of work networks that had kind of a fee market, you could kind of reason about what that change would do. Sorry, I am leading into a question here, I'm just giving some background. And then COVID, if I seem to remember right, was like parody technologies maintained it for the old open Ethereum parody climb, sort of the idea. And I think now the execution layer is a spec, there's some value behind testing clients. So I guess just to sum it up to a question, both testing features and execution layer specs, has there any thought behind testing those kind of things moving forward, spinning up test nets or forks of test nets to do that? Sorry, I don't think I got the question. I don't have the speakers, if you could just try to speak up a bit. So testing specific features of Ethereum forks like a fee market changes, or testing or validating the execution spec was sort of the goal, because you had like open Ethereum or parody and geth, and whether they synced up or not in terms of whether executing EVM basically correctly was always a question, if they ever split. So that's what I'm asking, where is the test net infrastructure sort of going in terms of forks and things, they're just going to spin it up whenever, whatever I want to beat this to death. Yeah, I hope I understand the question correctly. So I was talking about public test nets today, and public test net is always a really final stage of testing everything. So if you want to test execution layer changes, content layer changes, and whatnot, you usually go from local simulations to permissioned deaf nets to a lot of holes until you actually get to a public test net. And these test nets, like when I recommend girly or sepulia, they will only get protocol upgrades that have been sufficiently tested before. I don't know if this answers your question. Okay. Hey, Alfred. That's loud. Do you know why did the mergers happen the way around they did? Wouldn't it have been more logical for Gaulie to continue as a proof of authority? I think I have to come down. I just need to read. I'm just wondering why the mergers happened the way around that they did, as opposed to Gaulie continuing as a proof of authority and sepulia transitioning. Yeah, thank you. That's a very good question. The reason is that it merged with the Prata test net, which used to be a consensus layer test net for a very long time, where many teams already tested running validators for more than a year or one and a half year. So it was already the proof of stake test net available. And it was decided not to launch a new test net for Gaulie specifically and just use the existing one. So that's why we had this flip. It was also discussed to maybe have a new deposit contract on Gaulie, but in the end they decided it's actually worse for testing the merge to do the big merge. Because Prata was also the only consensus layer test net that had about approximately the same amount of validators as main net. Yes, and it was very, very valuable for specifically the consensus layer teams to not sunset this Prata test net. And you cannot move this Prata test net to another execution layer because it's all linked to the deposit contract. Have validators or the external participants on these test nets and you need to do a bug fix? When you need to do a bug fix on the test net code, are the external participants such as validators having to rebuild their validators on a new machine image or a new version of the code base? And how often does that happen during the test net phases? What's the question? If there's a bug fix on a test net, how often you have to rebuild your clients? Yeah, what's the workflow when there is bug fixes applied to the test nets? If you are a validator, there might be a protocol bug. So does the validators get coordinated and they redeploy their nodes multiple times during the test net rollout? Yes, this is basically, the answer is yes, but this happens very rarely because most bugs are usually not caught on test nets, but much, much earlier. Thank you everyone.