Pithos public merge testnet installation on fresh Ubuntu (first preview)
EthStaker Special Events · November 2020 · 27:00
This EthStaker walkthrough installs the Pithos public merge testnet on a fresh Ubuntu machine, giving node operators a first preview of the setup process. The session grounds the installation within Ethereum's broader network upgrades work as client software prepares for the transition to proof-of-stake.
Speakers
Topics
From EthStaker Special Events, hosted by Eth Staker.
Transcript
uh we don't we don't do great without organization hey everyone i'm superfiz um i am here with a bunch of my friends from eatstaker i hope this is recording uh we usually have michael's help with our video engineering but he is unavailable right now but we're so excited to get this pithos test net running that uh we're just like screw it we're gonna record it uh so i'm here with uh e-stakers like lamboshi who you know is nolan hello um buddha who you know is buddha hi uh colfax who is also around steakhouse and uh so who wants to tell us what
we're doing today so basically uh peritosh put a guide together on how to connect with the new merch testnet basically our ten or five step guides on how to run the execution client so the e4 nodes which we know as gaf for example and also the consensus client which is lighthouse or prism which what we don't have yet is the validator client and the keys so we only have the beacon node and the gaf nodes but those are coming soon as well awesome and so what we're going to
demonstrate today uh it really should take just a few minutes is the installation of this merge client test net from scratch um if you've ever tried to run some of this stuff you might know that the hardest thing is getting the right environment like launching it is usually one or two commands but getting to the place where you can launch it is kind of building from scratch so right now i am updating a brand new installation of ubuntu 20.04 um i'm actually running this from a desktop install because i i couldn't find my server install usb and so the only package i've installed is open ssh so i could dial into it from across
the room and then as soon as i started i did an update an upgrade i will post a link to these very simple instructions um or i would maybe not symbol their verbose they give you every command you'll need so that you don't have to try to figure it out as you go the only thing this really requires um is a good docker install and docker is not difficult to set up but there are a few commands and those are going to be linked here so colfax do you want to tell us what's the difference between um so we have this eth1 execution layer and the eth2 consensus layer how do
these two fit together that's a great question so basically the way the theorem works right now is the execution layer is sort of what you know and love is ethereum so transactions mean process interaction with smart contracts etc and the consensus layer is run by what's called proof of work that is the mechanism for how all these different nodes can agree on sort of what is true and what transactions are valid as a user of ethereum though what you normally are interacting with is uh sort of execution that happens on the
ethereum network and so as a user you're not actually going to notice too much difference after this merge happens or on this new net because you're still going to be interacting with ethereum as you know and love but the consensus layer which is what is currently proof of work is going to be replaced with something called proof of stake which if you're watching this video you probably know what it is and so ethereum's not going anywhere uh it's not going to change the way you interact with it very much other than the fact that it proof of stake is going to be what's used under the hood to decide on what transactions are valid versus proof of work is that a good answer that's a perfect explanation and that that kind of well
i'm still running updates in the background i thought it was so valuable to actually run these updates live um it is still running in the background as we're doing that um i want to show you that it's still going i would like to pivot actually quickly while you're running those updates i so i i was gonna say i've never run that command before i have run that command before had i not run that command before what's going on on your computer right now sure uh so this is uh like i said it's a fresh ubuntu 20.04 desktop installation um we use 24 20.04 even though it's a year old it is the long-term support version of ubuntu uh so it's generally the favored build environment um and i'm really just
installing all of the updates that have come out in the past uh probably like 18 months for this build it just takes a while but i did want it to be as authentic as possible and show this um it should finish in a minute but this whole move to proof of stake i think about it mostly in terms of power usage uh nolan you had some really interesting tweets about that difference in power usage can you tell us why this change to proof of stake is such a big deal yeah i mean we're going to see probably a 99 or greater reduction in the power usage and basically the reason for that is
with proof of work it's a race to see who can propose the next block so basically that results in people amassing as much hash rate and using as much electricity as is possible with proof of stake the next proposer is just randomly chosen and in that case it's not a race and you don't need to have beefy hardware to try to win that race awesome yeah so uh it ends the arms race uh which other cryptocurrencies other we kind of think about two two major generations of cryptocurrencies there's
the first generation which is proof of work which is bitcoin um and then you have kind of the second generation which i think of as the eath killers um they are a lot of newer networks that do mostly like distributed proof-of-stake stuff where they have like 20 nodes or a hundred nodes and they are distributed proof of stake but they're not really proof of stake uh how can does anyone want to talk about how ethereum solves that proof of stake problem without being what we know as a distributed proof of stake and while we do that i'm just going to reboot this box i think it is the main view right now so i'm going to reboot it and it's going to be offline while i do that
because i don't want to dox myself too hard buddha and i i had a great question what was that i i'm doing two things at one time i was like oh that's a great question any of these guys can answer it and everybody's like looking at each other you all figured out why i did this that's why i'm glad you didn't call on me take it away i don't i think i can't answer it in detail i mean you were basically asking what the difference between uh delegated proof of stakes it's the opportunity it's the decentralization of the network uh and that's that's the secret sauce is that ethereum exists as a truly decentralized
network where other networks uh exist as a group of delegates who actually control the network so what you're saying is that everybody who runs a validator in proof of stake on ethereum is voting you're not delegating your votes to a centralized group of smaller number of people right yep and that's that's the value uh you know everyone wants to know why is it 32 east that i have to stick with um and that's because it's the balance between having the most validators we can have on a without having too many or too few and 32 ether is kind of the sweet spot right now
the proof of stake network has over 200 000 individual validators and that that is uh kind of an amazing feat it also provides this really strong backbone for security so that when proof of work is added onto that we know that there are no individual actors who can really manipulate the network that almost makes me want to talk about client diversity about looking at that at some point kind of as i described i this is a fresh box i ran um sudo apt update and pseudo left disk upgrade uh and the next thing i need to
do is actually um we're gonna use docker and so i need to create a group for docker and add myself to that group and essentially these directions are just going to be copy paste um you can look them up otherwise or understand what they mean this just means modify the current user add the group docker to me i'm id 1000. to make this actually work super well i have to reboot again if i were smart i would have just done one reboot but and there are actually ways around that but uh so that that was like updating is the the
big thing the next thing we're going to do is install uh docker from the actual docker repo now if you're an ubuntu user you probably know that ubuntu ships with a version of docker in the repository uh it's not generally recommended for use i quickly tried it uh with this didn't have great luck with it so i was like i probably need to use the the official version and that just means installing some other stuff so i'm gonna hop back into that screen share and really just gonna copy a couple commands
i know that i'm going to get colfax what is git git is essentially a tool that allows you to track versions of your software commonly used and it's a tool that runs locator machine commonly it's used with a website called github which essentially is like google docs for code so you can collaborate with different people see people's changes have different versions of history so git is a tool where you can manage stuff locally and then when you actually upload your code to a website like github other people can see what's going on too and the next couple lines i'm just adding a
repo specific stuff so that i can install the official version of docker from um docker and not the one that's packaged with ubuntu and the real difference is just the um the version is is very far behind in the official one so this is going to give me docker community edition uh docker community edition cli and container daemon and i also need to install after this docker compose and these are really just uh one liners that i've copied from
docker hub uh i intend for them to be included in the instructions that are going to be linked on the bottom here all right so we have the environment set up i can run docker version somehow and docker compose version and those are the things that i need uh they don't they don't necessarily need to be the exact same that i have but if if you find out that it's not working that might be a good place to start all right who wants to tell me about this line
it's kind of an important one yeah this one go ahead and take it away it basically clones the repo from peritosh which includes the scripts for pulling and starting the execution and beacon great and he now i'm just handing off to his instructions that say go here uh create this directory execution data beacon chain and now uh i need to nano a file nano is just the easiest text editor that's available here i need edit pithos.vars and what i need to do is enter my ip
here i'm going to stop the screen share while i do that just so that i don't box myself because that's what i do [Music] how do you find your api shows up in logs later on too by the way super fast well i'm kind of wrecked then i guess i won't show them too long um hey buddha will you talk about how you got the ip yeah you can run curl uh space i fee ifconfig.me which returns tip and then you just paste it in there and when you're talking about your ip address you're talking about your public facing ip address or like if i'm behind a router do i want like the ip address in my machine
good question i believe it's the public ipa it doesn't say hot dogs yeah i mean the other one doesn't make sense though yeah yeah it's the public ip address if you go to a website too called like uh what is it what's my ipaddress.com i think what's my opinion it'll tell you what the internet thinks your ip addresses buddha forgets we're doing education sometimes and he's like everybody knows that but yeah we definitely want the external facing ip um not your you know your computer is going to have an ip like 192.168.1.4 or something but we're looking for the internet ip uh so i have modified that pitho stop vars and wow we are already there i can
copy this one liner to start the docker compose the environment file is pithos variables the configuration file is dockercompose.guest.yml um what if one client where are we gonna launch here i don't know if the other ones are supported i yeah i think death is the only one sport but there are nolan said that he tried other e2 clients i have a quick question what do you mean by each one client earlier we were talking about consensus and execution ah yeah and that's maybe i will definitely get into client diversity as soon as we wrap that up um there are a few eth one clients uh baysu
nethermind aragon open ethereum um but by far the most popular is guess i think it has about over maybe 70 of the clients or 70 of operators use death even though there are four or five different clients in a minute we're going to switch to talking about eth2 clients and that's where i want to get into diversity but the important thing to know is eth1 clients have lower diversity but they've also been live and kind of calcified for about six years whereas these two clients are relatively new and they are still error prone uh and the important thing there is uh it's
it's much more dangerous to rely on one client for eth2 because it's so new or for proof of stake whereas with um the current proof of work network we have a lot more clock hours or lendi hours to say um this works lindy hours being like the longer something runs the longer it's likely to run so when something is running for six years you can kind of say oh it's probably going to work tomorrow but if it's been up for like two hours you're like i don't know if it's going to work tomorrow we just used docker compose to create this guest and now i'm going to launch another command
and this is going to throw up a lighthouse version and so in the background now with docker they are running and we're going to view log files in just a minute um sorry that doesn't work that way the thing that i want to get to really quick so we have two two images running we have uh the consensus layer which is lighthouse beacon and we have the execution layer uh which is guess we formally know these kind of like eth1 and eth2 technically we like to call them consensus and execution so with all of that done there's also
i'm not great let's do is it docker log stash follow lighthouse beacon that work that's not gonna work is it what's the command for that uh let me stop sharing my screening code docker logs lighthouse underscore beacon dash after yeah what did i do wrong docker logs oh i did log okay uh and so now what we see is i'm following the beacon chain log oh i don't see your screen there
in yeah i'm going to control c so we'll get back to it your screen let's see what this chat message is oh great thank you um so docker logs dash f lighthouse beacon and i'm now following the lighthouse log showing that we are connected we are on epoch 82 which tells you this network is brand new some of you know a little more about
this and someone mentioned earlier uh who is running these validators and when will we be able to interact with it more uh i'm not i don't know who's running it but probably just declined this to test it and average user us will probably be able to send transactions next week and i'm not sure when we will be able to launch our own validators but i think it will be shortly after that great so we will need to set up a launchpad website and okay great uh i want to rant for client diversity about client diversity just as we're wrapping this up we chose lighthouse
here um and the the big issue with client diversity is that we have four five if you include low star which load star is still kind of ramping up four clients being prism lighthouse nimbus and tekku and right now we know that prism has the majority of the validations they have probably about 65 percent and so what we're looking at let's say lighthouse had the majority and we were running lighthouse if this client encountered an error um and let's say it had 66 of the network a super majority it could bring the network to a halt and so what we're working to do
is to uh get any majority client down below 50 so that there's no risk of or not no risk there's less risk of halting the if any one client has too many validators ideally we want them to be below 33 percent but for our first benchmark right now it's october uh 2021 by december 2021 the goal is to get prism below 50 so that we can have high confidence that when we do send this chain live that if prism halts that the network will continue
finalizing any other thoughts on that oh that was a good description if i if i'm running a majority client are there any guides available for me to follow uh oh that's great yeah like how would i go about switching so i would say and what are the risks too so oh yeah these are great questions so first off i would say i would encourage you to switch to nimbus um and the reason i'm encouraging nimbus is because it's a lightweight client that runs on almost any hardware uh we joke about it being able to run a toaster it actually does run on a raspberry pi um but so and it runs on single core devices so
any lightweight device can run nimbus and there are guides available on easttaker right now the pinned post on each staker that's reddit.comr eatstaker is a list of client switching guides nimbus actually puts out a great guide for switching from any client to nimbus because nimbus is so lightweight you could technically um while you're still on your validator you can install nimbus and get it synced up while you're running your existing validator and then when it's synced up literally all you have to do is turn off your old validator um remove it very well make sure there's no trace of it still
running i would encourage you to wait 15 20 minutes i would probably wait an hour just because i'm like that and then import those keys into nimbus and you're up and running so with that scenario your total downtime is really technically a 13 15 minutes for me it would be an hour it's so important to make sure that your old validator is no longer running because the risk here is that if you're nimbus and prism at the same time that um they will both send information to the network that will be seen as contradictory and that could lead to a slashing so
i know that sounds scary the risk really is very low if you're careful so for example if you have prism running in docker you'll need to make sure it's completely removed and make sure that it doesn't restart when you start your machine um you want it just completely gone but as long as you've verified that carefully and maybe even if you're not sure ask for help and say hey can you help me verify that then you have nothing to worry about the one of the best ways to verify that is let your machine run and watch the beacon chain for missed attestations because if you're if prism is down and it's not a testing and then you maybe you rebooted it and you check again to make sure it doesn't start with docker
um and you're not attesting then you know that you can start nimbus and begin validating there uh no one has asked to share his screen so i'm going to cut this out oh that's a great explanation guys uh no one you're a co-host now so this is lighthouse lodestar taku and geth running all at the same time and after we finish the uh video i'm gonna try to get some of the more execution layer nodes up and but uh
yeah the test net seems to be working well everything's uh taking along nicely here do you have an idea what are we looking for how how can we know that things are successful and that um we haven't melted down completely well i'm not really seeing any error messages and uh all three consensus clients are onslaught 26 59 so yeah they're all showing synced so it's looking good i would agree that that um being on the same slot is a great indicator of being on the same network one of the first things we look for in a new network is like divergence
in in slot counts so that's really gorgeous did you screenshot that no not yet i'll have to tweet it yes do we want to share anything else guys good i think that's it that's right so the new network is called pithos we got great instructions from parathas parroth i will take the extensive exhaustive instructions um and put them in a github in the bottom of this you'll see a link
to my instructions and paradosh's original instructions uh depending on your skill level of of what you want to work with uh so ideally anyone can get this up and running sounds great thanks guys for joining me i'm going to stop the recording and take care everyone uh yeah