Post-Merge Testnets by Afri Schoedon | Devcon Bogotá

foreign [Music] [Music] 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 Francis already mentioned I launched the early 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 um and then specifically take a close look at the implications of the merge on the test Nets and finally give a quick guide to selecting a test net for your project so yeah let's dive right into the protocol history everything started with a test net does anyone here know what's the meaning of the ethereum Genesis extra data is you might know the Bitcoin extra data or against this accelerator contains a news headline does anyone know what the meaning of the ethereum accelerators it's actually a block hash from a test net um ethereum was uh publicly fairly launched by announcing a block number on a Olympic test net that was 128 201 and once this test net was mined on the uh test once this block was mined on the test net this hash could be inserted into the ethereum Genesis and the public mining on ethereum mainnet could start Olympic was the last pre-release testnet before the issue mainnet was launched and the first public assumed testnet after the launch was more than was a proof of work testing it using the same 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 Defcon 2 in 2016 an attacker exploited the long discrete time of the X code size op code in one of the client implementations which caused the denial of service of the issue main net here's a photo of the amazing guest team investigating the issues and coming up with a solution to address this issue two subsequent hard Forks were scheduled for ethereum the tanguine whistle Fork to fix the attack vector and dispers dragon Fork to allow cleaning up the state afterwards however this protocol change caused a consensus failure on Modern this was specifically caused by the different ways how the clients handled this custom starting loans and it was then decided it's not not a good idea to have a custom protocol on a test net and therefore modern was discontinued and replaced by a new testnet called ribstone groups was the first tester to launch with shine ID right from Genesis the chain ID served the purpose of a simple replay protection according to EIP 155 so the roof's intestine was also powered by the isage 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 test bet so attackers moved to DOS rubstone and the test net was unusable for weeks in response parity launched the coven proof of authority test net and guests launched during the approval for Authority test net for the first time ethereum had a way to have a more stable test net environment however coven used the parity Aura consensus engine and drink be used to guess click consensus engine and they were not con compatible coven was therefore only accessible through the parity serum stack whereas ring B was only accessible by gas or tooling that relied on the gas stack so in 2018 the girl initiative attempted to address this by ideating a cross-client proof of authority test net in the end the initiative managed to implement click and parity and subsequently in 2019 the early Testament was launched as a first cross-client proof of authority test mode with validators from both guests and parity ethereum at the same time coincidentally after Defcon I believe the pantheon client was released so there was a even a third client available for running validators on this test net and soon after also nazamine joined the validator set you know later the same year parity except uh ethereum and um 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 Robson and Rigby on the amazing ethereum Foundation block they argued the older test Nets are harder to maintain due to Growing history and state and the growing complexity to run the test net setup so in foresight however new test net was launched sipolia interestingly sepolia that was just launched not even a year ago it was launched as a proof of work test net using the same algorithm as main net back in the day there was a first time since uh the Robson launched in 2017 that we actually launched a new proof of work test net the reason was potentially to have another test net similar to mainnet to allow for once again testing the merge and now mainnet conditions okay so let's um recap the test Nets prior to the merge modern is fairly dead it was replaced by Robson in 2017. was just deprecated a couple of weeks ago um coven diet was poverty leaving ethereum Rigby was also deprecated just a couple of months ago and that leaves us with scurry and sympolia as the latest test nets for ethereum and now let's just uh take a look at what it actually means to merge uh yeah I took a lot of time to build these slides so in ethereum this the merch 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 um and this consensus layer Beacon chain replaces the Legacy proof of work consensus or the other consensus uh mechanisms on the execution layer here depicted in red so the slide shows the timeline of the test net mergers and I added a lot of details here I'm standing in front of it I had a lot of details here but let's revisit this slide in a bit after talking a bit about the implications so um just to recap a proof of work consensus mechanism is permissionless as parental motor consensus so you can just turn on your CPU Miner and hope for a block in theory on the other hand a 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 a token and you can stake it to take part in consensus so what does it mean for SEO mainnet the merge obviously moving from proof of work to proof of stake um just does not change much in this perspective it was permissionless before the merge is still permissionless after the merge but how does it look like for the test Nets so girly was merged with a beacon chain test net and um to access to get access to the consensus on the growly test net prior to the merge uh was con was permissioned so girly was running a community maintained Valley 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 girlies so girly used to be permissioned is now permissionless but what about zipolia um as I mentioned prior to the merge it was powered by the permissionless esash a proof of work algorithm here you can see my sepolia Miner I was happy that I once again can mine a test net um and yeah I did not ask for permission I can just I was just able to mine the blocks I got a lot of zipolia either um but now there's something unique about um the C polier Beacon chain um since it was apparent that girly will no longer be permissioned there was actually the the Quest for having another permission test net to have a certain stability guarantees so it was decided that the polio gets a beacon chain with a modified deposit contract that does not accept regular ether deposits instead attracts the valid data sets through an erc20 token so in that case zipolia is a proof of authority version of The Beacon chain and therefore the access to the polio consensus is permissioned so let's take a look at this overview again um this is a timeline actually on the x-axis axis the first test net to merge was rubson 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 permission um esc20 token that you require to take part in consensus I call it for Simplicity proof of authority here because access to this consensus is actually permissioned um and then girly merge was Prada and test net were exactly the opposite happened uh the proof of authority test and it became a proof of stake girly test net 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 test net landscape I showed you that groups merged however it has been deprecated by the ethereum foundations a protocol support team and it leaves us with uh girly and simpleia is the only long-standing public post merge test Nets so I will conclude my presentation with the test net selection guide I mean it's only two testers how hard can it be I um I mentioned how amazing Museum block is it's just a great resource I found this slide on on the ethereum Block um basically just Recaps what I just said um the open value data set for girly on the one hand the closed value data set for zipolia on the other hand um obviously since Gurley is much older it has a large state that gives some better Network effect so if you have an application that you want to deploy Deploy on girly and you require other applications or interfaces you might find some on the polio girly but not on the polio because the polio is fairly new and not many applications and libraries are deployed yet however it's also longer to sink and more involved to run girly infrastructure so to summarize this please do use girly test net as it is most similar to the ethium 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 uh or if not even the only test Network you can actually conduct this um yes please also do use the sepolia testnet um sepolia 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 a recommending uh to test your applications or even migrate your applications to sepolia instead of Gurley at this point yeah do not use groups and obviously um I when 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 Rigby even though there is some long-term support planned for rink B for almost another year but you will potentially not get more protocol upgrades on that Network so I would also not recommend using ring B and that regard yeah right there are some caveats so as I mentioned the girly test net has Esa supply issues due to the sheer amount of users trying to test their validator set up each validator requires 32 is and if you want to have a more involved setup with I don't know 1000 validators it quickly becomes a huge burden huge problem to access these uh required test net 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 Gurley is also fairly old so it has it comes with a Felipe or a rich history and 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 in combination and yes the polio is uh uh relatively new as I mentioned it 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 uh even metamask has a sepolier test Nets which now so um it's happening I'm really happy that we get all these Integrations now oh yeah okay um 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 early and go straight to run your stack on sepolia okay this was my talk um please use girly or sepolia going forward um find me for some spare Visa cards from East Berlin they are pre-loaded with girly and sipolia Isa so if you want some I will not throw them into the audience if I just fight me after the talk um 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 sepolio ought to be to help in the infrastructure short answer is you can't because as I mentioned even though it's proof of stake you need a special erc20 token to get access to this value data set and you would basically have to Google support your GitHub repository and there is an issue where you can request to be added to this value data set but in general not many teams will be accepted just to keep it really a small value data set maybe two questions here um one when eip1559 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 like kind of a fee Market you could kind of Reason about sort of what that change would do sorry I am leading into questionnaire I'm just giving some background and then coven if I seem to remember right was like parody Technologies maintained it for the old open ethereum parity climb sort of the idea and I think like now the execution layer is a spec there's some value behind um you know testing clients so I so I guess Mike just to sum it up to a question both testing features an execution layer specs is there any thought in behind testing those kind of things moving forward spinning up test Nets or Forks of test Nets to do that so I'm sorry I don't think I got the question it's also I don't have the speakers if you could just try to speak up a bit or so so specific testing specific features of ethereum forks like a fee Market changes or testing the or validating the the execution spec was sort of the goal because like you had like you know open ethereum or parity and Geth and whether they synced up or not in terms of where they're executing uh you know evm basically correctly was always a question right if they ever split so so I that's that's what I'm asking where are the where is the test net infrastructure sort of going in terms of forks and things they're just gonna spin it up whenever or whatever I want to beat this to death um yeah I hope I understand the question uh correctly um so I was talking about public test Nets today and public testness is always a really final stage of testing everything so if we want to test execution layer changes the content layer changes and whatnot you usually go from from like a local simulations to to permissioned deafness to um through like a lot of hurls until you actually get to a public test net and these test Nets like when I recommend Gurley or sepolier they will only get protocol upgrades that have been sufficiently tested before um I don't know if this answers your question okay um do you know why did the mergers happen the way around they did could wouldn't it have been more logical for for goalie to continue as a proof of authority sorry I think I have to come down I'm just wondering why the merges happened the way around that they did as opposed to gawley continuing as a proof of authority in sepolia uh transitioning yeah I think that's a very good question the reason is that it merged with the product test net which you used to be a consensus layer testment for a very long time where many teams already tested um running validators for more than a year or one and a half year so it was already this proof of um stake test net available and it was decided not to um launch a new test Beacon chain test net um for currently specifically and just use the existing one so this is that's why we had this flip that was also discussed so maybe have a new uh deposit contract on Gurley but in the end they decided it's actually worse for testing the merge to do the big big merge because product was also the only uh consensus layer test method had about approximately the same amount of uh values and mainnet as mainly yes and it was very very valuable for a specifically the consensus player teams to have um to let to not sunset this prata test net and you cannot have you cannot move this product testing it to another execution layer because it's all linked to the uh deposit contract to 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 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 uh if there's a bug fix on a test net how often do 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 uh yes this is basically uh yeah the answer is yes but um this happens very rarely because most bugs are usually not caught on test Nets but much much earlier thank you everyone