Mijn reis om een ​​validator te worden op Ethereum 2.0, deel 2

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogOntwikkelaars

Mijn reis om een ​​validator te worden op Ethereum 2.0, deel 2

Wat zijn enkele dingen waarmee u rekening moet houden bij het kiezen van hardware en software om een ​​Ethereum 2.0-validatorclient uit te voeren? Door Coogan BrennanDecember 5, 2020Geplaatst op 5 december 2020

Mijn reis om een ​​validator te worden op Ethereum 2 0 Deel 2

Let op: je kunt nog steeds validator worden op het Ethereum 2.0-netwerk! Er zal een wachttijd zijn om als validator te worden geactiveerd – vanaf 4 december 2020 is de wachttijd ongeveer 9,9 dagen. Bekijk de stappen om uit te zetten in deel 1 van deze serie.

  1. Disclaimer
  2. Invoering
  3. Overwegingen bij de validatie van de configuratie
  1. Toekomstbestendige hardware
  2. Om al dan niet een Eth1-client te runnen?
  3. Virtuele versus lokale hosting
  4. Eth2-klantkeuze en het vermijden van sancties
  • AWS-instantie instellen
    1. Besturingssysteem
    2. Prijsstelling
    3. Opslag
    4. Poorten
    5. SSH-sleutels en instantie starten
    6. Teku installeren
      1. Voorwaarden
      2. Installeer binair
      3. Maak een niet-rootgebruiker aan
      4. Maak een systemd-service
      5. Lancering
      6. Disclaimer

        Dit is een bericht dat ik aan het schrijven ben als medewerker van ConsenSys en iemand die van plan is om in de bakenketen te spelen. De eerste verklaring betekent dat ik prioriteit geef aan ConsenSys-producten (ConsenSys-producten zijn doorgaans de beste in hun klasse voor Ethereum en ik heb ook toegang tot technische teams die me kunnen helpen bij het beantwoorden van vragen en het oplossen van problemen). De laatste verklaring betekent dat ik optimaliseer voor kosten en gebruiksgemak: ik heb geen duizenden ETH om substantiële beloningen op te leveren, dus ik neem een ​​paar snelkoppelingen. Dit zijn beslissingen die ik heb genomen om het inzetten op Ethereum 2.0 zo eenvoudig en toegankelijk mogelijk te maken voor individuen, maar er zijn afwegingen voor decentralisatie en privacy. U kunt echter de grote lijnen van de onderstaande tutorial volgen en verschillende keuzes maken. In feite, als je dat kunt, zou ik je aanmoedigen om dat te doen! 

        Ten slotte is staken in Ethereum 2.0 zeer experimenteel en gaat het om een ​​langdurige verbintenis (ik reken drie jaar toe). Doe alsjeblieft niet mee als je je niet prettig voelt bij het hoge risiconiveau dat gepaard gaat met iets dat nog in ontwikkeling is. Als u niet zeker weet of u moet inzetten, sluit u dan aan bij de ConsenSys onenigheid en vraag het in het # teku-public kanaal. 

        Invoering

        In het vorige bericht hebben we de redenen voor de implementatie van Ethereum 2.0 besproken en hebben we 32 ETH in het Ethereum 1.0 mainnet Deposit Contract doorlopen. We hebben de sleutelgeneratie besproken en hoe het uitzetproces is verlopen Lanceerplatform koppelt Ethereum 1.0 aan 2.0.

        Op 23 november werd het minimum aantal ingezette ETH om Ethereum 2.0 te lanceren – ongeveer 524.288 – gehaald. Mensen kunnen blijven deelnemen aan het contract en het aantal validators is op 4 december gestegen tot meer dan 33.000.

        Aaron Davis van MetaMask deelt zijn gedachten in het interne ConsenSys Slack-uitzetkanaal 

        Hoewel het buitengewoon opwindend was om als validator in het Genesis-blok te komen, had ik seconden later een vergelijkbare ervaring als mijn collega Aaron Davis in ons interne ConsenSys-uitzetkanaal: voor welke gekke taak had ik me aangemeld? Gelukkig heb ik toegang tot ongelooflijk briljante en technische mensen die liefdadig genoeg zijn om deze gids wat tips, aanwijzingen en inzichten te geven over het runnen van uitzetinfrastructuur. Ik hoop hier een fractie van dat waardevolle advies door te geven aan andere geïnteresseerde partijen.


        Dat is wat het eerste deel van dit artikel zal zijn: wat zijn enkele dingen waarmee u rekening moet houden bij het kiezen van hardware en software om een ​​Ethereum 2.0-validatorclient uit te voeren? Het tweede deel behandelt de specifieke hardware / software-combinatie die ik heb gekozen voor mijn validator-client. De keuzes die u voor uw configuratie maakt, zijn afhankelijk van uw middelen, persoonlijke voorkeur en technische capaciteit. Ik zal mijn best doen om te benadrukken hoe persoonlijke vooroordelen en omstandigheden mijn keuzes hebben beïnvloed.

        Ten slotte, voordat we erin springen, wil ik herhalen dat deze berichten bijna als dagboekaantekeningen zijn voor mijn ervaring met het uitzetten van 32 ETH (zij het journaalboekingen met uitgebreide technische kanttekeningen). Als zodanig kan ik mijn aanpak een beetje veranderen naarmate de bakenketen vordert. Ik dacht bijvoorbeeld dat ik zeker AWS zou gebruiken. Zoals u hieronder zult lezen, heroverweeg ik dat nu. Ik ga ook heel duidelijk zijn over het financiële element van uitzetten. Uitzetten is een manier om het Ethereum-ecosysteem te ondersteunen, maar voor duurzaam openbaar gebruik moet het ook toegankelijk en mogelijk zijn voor mensen die de ETH hebben om dit te doen. 

        Toekomstbestendige hardware

        Aan de basisvereisten voor het uitvoeren van een validator is tegenwoordig relatief eenvoudig te voldoen. Mara Schmiedt en Collin Meyers ‘ Validator Gids op Bankless heeft een goed overzicht van de minimumvereisten. Het meest uitdagende aspect van het bepalen van Ethereum 2.0-validatieapparatuur is het in evenwicht brengen van de huidige behoeften van de Beacon Chain Phase 0 met eventuele toekomstige, momenteel onbekende eisen naarmate de ontwikkeling vordert. (Dit is geen probleem als u het prettig vindt om uw validator nauwlettend in de gaten te houden en snel en gemakkelijk wijzigingen aan te pakken) 

        Ben Edgington, Teku Project Manager en uitgever van Eth2.news, voorzag me van enkele randgevallen waarin het netwerk meer van de validatorclient zou kunnen vragen. Op korte termijn zou de grootste zorg zoiets zijn het Medalla tijdserver incident, waarin een bug en daaropvolgende fix in de Prysm-client de afronding op het testnet stopzetten (grofweg kon het netwerk geen “blokken produceren”). Omdat er geen finaliteit op het netwerk was (geen “bevestigde blokken”), moesten validators veel meer transacties in hun RAM bewaren dan normaal. 

        Machines met 8 GB RAM – wat onder normale omstandigheden meer dan genoeg zou zijn geweest – begonnen problemen met “onvoldoende geheugen” te ondervinden die mogelijk tot slashing hebben geleid. Een piek als deze, hoewel ongebruikelijk, is niet uitgesloten voor fase 0-mainnet.

        Toekomstige onduidelijkheden in de configuratie van het netwerk zijn het samenvoegen van Ethereum 1.0 en 2.0 en de introductie van sharding. We weten nog steeds niet wanneer die samenvoegingen zullen plaatsvinden of wat ze precies nodig hebben. Ik zou graag een sterke CPU-backbone hebben die fase 0 ingaat (4 virtuele kern, 16 GB RAM met 100 GB SSD) en dan mijn aandacht vestigen op toekomstige aanpassingen rond opslagruimte (laat hier bewegingsruimte over). Let op: dit kan overdreven blijken te zijn en beloningen opeten.

        Dat zijn de “bekende onbekenden” van de toekomst. Laten we vandaag de belangrijkste configuratiebeslissingspunten voor validators bespreken.

        Om al dan niet een Eth1-client uit te voeren?

        Het is een overgangsritueel waaraan ik onze bootcamp-studenten zo vaak mogelijk probeer te onderwerpen: het synchroniseren van een Ethereum 1.0-client. Het is een publiek geheim dat het hosten van een ‘volledig’ Ethereum 1.0-knooppunt eerder een daad van liefde is dan een verharde Prisoner’s Dilemma-oplossing. ‘Volledig’ moet tussen aanhalingstekens worden geplaatst, omdat zelfs kernontwikkelaars van Ethereum het moeilijk hebben om het eens te worden over een definitie van wat ‘volledig knooppunt’ eigenlijk betekent.

        Over één ding kunnen we het allemaal eens zijn: het kost meer tijd en opslagruimte om een ​​Ethereum 1.0-client te synchroniseren dan je zou denken. Onze validators moeten een manier hebben om de Ethereum 1.0-netwerkdatabase te doorzoeken (we zullen later ingaan op waarom). Als u de ruimte en hoofdpijn van lokale synchronisatie wilt besparen, kunt u een Infura-eindpunt gebruiken, die gratis beschikbaar is bij registratie. 

        Hoewel dit een aanzienlijke opslag en logistieke zorg scheelt, wordt een zekere mate van decentralisatie voor de Eth1- en Eth2-netwerken tegelijkertijd opgeofferd. Als Infura ten onder zou gaan, wat buitengewoon zeldzaam is, maar wel voorkomt, dat zou een rimpeleffect veroorzaken bij de Ethereum 2.0-validators die het gebruiken voor hun Ethereum 1.0-eindpunt. Iets om over na te denken!

        (Voor de duidelijkheid: de moeilijkheid om een ​​volledig Ethereum-knooppunt te synchroniseren heeft te maken met de aard van de Ethereum-wereldstaat, niet met de Ethereum 1.0-kernontwikkelaars die geweldig werk hebben geleverd bij het omgaan met dit buitengewoon uitdagende probleem.)

        Virtuele versus lokale hosting

        De volgende overweging voor mij was het lokaal hosten van een validatorknooppunt (bij mij thuis) of virtueel (op een virtuele serviceprovider zoals Amazon Web Services (AWS), Digital Ocean, enz.). Zoals ik in het vorige stuk al zei, vertrouw ik mezelf niet om vanuit huis een consistent validatorknooppunt te draaien, zelfs niet op een oude laptop die ergens is opgeborgen. Onhandig en maf, ik zou het omdraaien of het vergeten.

        Ik kies ervoor om mijn node op AWS uit te voeren, omdat dat is waar ik het meest bekend mee ben (nadat ik dit hele proces heb doorlopen, twijfel ik echter aan deze beslissing. Ik zal dit later bespreken). De wisselwerking hier is opnieuw decentralisatie: als AWS uitvalt of problemen heeft (zoals het onlangs deed), Ik ben overgeleverd aan hun genade. Als genoeg mensen knooppunten op AWS draaien, kan dit van invloed zijn op het grotere Ethereum-netwerk.

        Mensen zullen waarschijnlijk zelf voor deze selecteren. Lokale hosting is een speciaal soort project en niet iedereen heeft de benodigde tijd, middelen of inzet. Hoewel virtuele hosting een centraliserende kracht is, kies ik ervoor om ermee aan de slag te gaan vanwege het gebruiksgemak en (hopelijk) gegarandeerde uptime. 

        Als u lokaal een validatorknooppunt wilt uitvoeren, kunt u nog steeds de algemene aanwijzingen van deze zelfstudie volgen, De uitstekende reeks tutorials van Somer Esat met verschillende klanten of synchroniseer zelfs een Raspberry Pi Model 4B met 8GB RAM met Ethereum op ARM. (Synchroniseren op Raspberry Pi is nog steeds erg experimenteel en mensen moeten wachten tot Ethereum op ARM-team de stabiliteit bevestigt)

        Eth2-klantkeuze en het vermijden van sancties

        Een andere belangrijke keuze is de Ethereum 2.0-client onder de bestaande klanten: Vuurtoren, Lodestar, Nimbus, Prysm en Teku. Ik ben sterk bevooroordeeld ten opzichte van Teku en niet slim genoeg om de fijnere punten van de klanten te bespreken. Dit artikel is een behoorlijk overzicht van de prestaties van de klant op Medalla. (Houd er rekening mee dat de Medalla veel meer van processors eiste dan mainnet.)

        Proof of Stake bevat expliciete belemmeringen om correct gedrag op het netwerk aan te moedigen. Deze nemen de vorm aan van valse validators omdat ze offline zijn en de meer dramatische beweging van snijdende actoren die, al dan niet bewust, kwaadwillende actie ondernemen tegen het netwerk..

        Het meest voorkomende probleem is ervoor te zorgen dat uw validator beschikbaar is voor het netwerk. Dit betekent dat u ervoor moet zorgen dat uw validator online is. Er is de DevOps-benadering van dit probleem – het creëren van het monitoring- en waarschuwingssysteem om u te waarschuwen als uw validator offline gaat – die ik hier niet zal behandelen.

        Maar er is een andere manier om niet beschikbaar te zijn op het netwerk, en dat is als uw cliënt zich om de een of andere reden misdraagt. Na de tijdserverbug veroorzaakte een netwerkvertraging op Medalla, kwamen Eth2-kernontwikkelaars samen om te ontwikkelen “[A] standaardformaat voor het overdragen van de ondertekeningsgeschiedenis van een sleutel stelt validators in staat om gemakkelijk tussen clients te schakelen zonder het risico te lopen dat ze conflicterende berichten ondertekenen.” Niet alle klanten hebben deze bescherming, maar Teku wel. Hier kunt u lezen over het gebruik van Teku’s Slash Protection (wordt standaard uitgevoerd) inclusief het migreren tussen Teku-knooppunten of een niet-Teku naar Teku-knooppunt.

        Als je problemen hebt met je client en het hele netwerk opnieuw moet opstarten, moet je je bewust zijn van zwakke subjectiviteit. Met Proof of Work kan iedereen teruggaan naar het genesisblok van het netwerk en zonder vertrouwen de netwerkstatus helemaal opnieuw opbouwen. Proof of Stake heeft in dat opzicht echter een addertje onder het gras: als een derde van de netwerkvalidators op een bepaald punt vertrekt en toch doorgaat met het ondertekenen van blokken en attesten, kunnen ze de netwerkstatus wijzigen en die valse gegevens naar een knooppunt sturen dat wordt gesynchroniseerd met de netwerk als de kwaadwillende actoren het synchronisatieknooppunt vangen voordat het synchronisatieknooppunt bereikt waar de validators hun geld hebben opgenomen. Je kunt er hier meer over lezen, maar het korte antwoord is dat je een ‘zwakke subjectiviteitscontrolepunt’ of een gecodeerd statusbestand nodig hebt, in wezen een archief van het netwerk. Teku biedt voor beide opstartvlaggen.

        De laatste bezorgdheid over een boete is de meest ernstige: snijden. Slashing treedt op wanneer een staker tegen de regels van het netwerk werkt. Het is iets anders dan gestraft worden in plaats van offline te zijn. Het werkt actief tegen het netwerk door tegenstrijdige validatiegegevens in te dienen. Er zijn echt geweldige materialen om meer te leren over slashing en hoe je dit kunt voorkomen:

        Het belangrijkste is om niet één validatorsleutel op meerdere clients uit te voeren. Blijkbaar is dit de oorzaak van de eerste slashing-gebeurtenis ooit, die plaatsvond op 2 december. Sindsdien zijn er een aantal schuine strepen geweest! Als u van de ene instantie naar de andere migreert, controleert u in viervoud dat u niet twee computers met dezelfde sleutel zult laten werken:

        Papa Ben vertelt het zoals het is. Bron

        AWS + Infura + Teku Validator Configuratiespecificaties

        Mijn Genesis-blokopstelling:

        Besturingssysteem: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

        Bewerker: Processor uit de Intel Xeon Platinum 8000-serie, 3,1 GHz. (Amazon-webservice)

        Geheugen: 4 virtuele kernen, 16 GB RAM (Amazon Web Service)

        Opslag: 100 GB SSD, 300/3000 IOPS (Amazon Web Service)

        Ethereum 1.0-client: Infura-eindpunt (gratis laag)

        Ethereum 2.0-klant: Teku

        Als ik alle bovenstaande overwegingen doornam, wist ik niet zeker wat de beste benadering was om een ​​validator-setup te bouwen. Voor mezelf zou ik graag een machine kiezen en over het algemeen geen zorgen maken over het veranderen van deze gedurende ten minste twee jaar. Dit helpt bij de algehele validatiekosten (ik kan een aanzienlijke korting krijgen als ik een paar jaar bij een virtuele provider ben ingesloten) en ik ben niet bijzonder behendig met het opstarten van servers. Deze toekomstbestendige of ‘over-specific’-aanpak maakt mijn leven de komende twee jaar hopelijk een beetje gemakkelijker.

        Aanvankelijk had ik er vertrouwen in dat AWS het beste virtuele platform was en dat dit de service is die ik voor deze post en de volgende zal gebruiken. Nadat ik het hele proces had doorlopen, realiseerde ik me echter dat AWS misschien een overkill is voor de individuele ontwikkelaar. De echte kracht van AWS lijkt het vermogen te zijn om dynamisch op te schalen om aan de vraag te voldoen, die hoge kosten met zich meebrengt. Dit is economisch zinvol voor een grootschalig project op bedrijfsniveau, maar voor individuele Ethereum 2.0 actueel de eisen van de klant vereisen een dergelijke strengheid niet.

        Ik ga door met AWS, maar geniet ook van de mogelijkheid om een ​​instantie op Digital Ocean uit te voeren, wat wellicht geschikter is voor een individuele ontwikkelaar. Daarover later meer.

        Stel een Infura-account in

        Ik kies ervoor om Infura te gebruiken als mijn Ethereum 1.0-eindpunt. Voorlopig kijkt de bakenketen naar het depositocontract op Ethereum 1.0 om nieuwe stakers te activeren wanneer ze op de juiste manier 32 ETH hebben gedeponeerd en de juiste BLS-handtekeningen hebben ingediend.

        In de toekomst zal de bakenketen beginnen met het testen van verdere verwerking door statusinformatie van Ethereum 1.0 te gebruiken om parallelle controlepunten op de bakenketen te creëren..

        Zoals we hierboven vermeldden, zijn er twee manieren om zicht te hebben op het Ethereum 1.0-netwerk. Een daarvan is het synchroniseren en actief onderhouden van een Ethereum 1.0-knooppunt, waarmee een lokale Ethereum 1.0-statusdatabase wordt gemaakt. De andere is om een ​​service zoals Infura te gebruiken, die een eenvoudig Ethereum 1.0-eindpunt biedt, toegankelijk via HTTPS of WebSockets.

        Teken hier voor een account. Zodra u een account heeft, klikt u aan de linkerkant op het Ethereum-logo.

        Klik op “Nieuw project maken” in de rechterbovenhoek

        Geef uw project een naam (de mijne is “Eth 2 Validator”), en ga naar “Instellingen”, zorg ervoor dat uw netwerkeindpunten “Mainnet” zijn en kopieer het HTTPS-eindpunt:

        We zullen dit later gebruiken voor de opstartopdracht van onze Teku-client!

        AWS-instantie instellen

        Het opzetten van een EC2-instantie op Amazon is eenvoudig. We zullen hier en daar een paar aanpassingen doen om onze virtuele instantie goed te laten spelen met Teku.

        Maak een AWS-account aan (anders dan een Amazon.com-account) en log in op AWS Console. Ga naar de EC2-pagina, die er ongeveer zo uitziet:

        Klik op de knop “Launch Instance”. Je krijgt dan het volgende scherm te zien:

        Besturingssysteem

        Hier selecteren we welke machine-afbeelding (die ik beschouw als een besturingssysteem) we willen gebruiken op onze virtuele instantie. Ik selecteer Ubuntu Server 20.04, een op Linux gebaseerde serveromgeving. De Ubuntu Server-omgeving heeft een paar belangrijke optimalisatieverschillen met de Ubuntu Desktop-omgeving. Het belangrijkste verschil voor onze doeleinden is dat Ubuntu Server geen grafische gebruikersinterface (GUI) heeft. Waar we heen gaan, is er alleen een opdrachtregel! Brengt me terug naar mijn Apple II-dagen.

        Nadat we ons besturingssysteem hebben geselecteerd, kiezen we ons instantietype:

        Ik vind dit menu nogal overweldigend, dus ik ga het een beetje voor je uitsplitsen. Hier selecteren we de rekenkern / RAM-vermogen / CPU voor onze machine. Het is het “ruwe” of “actieve geheugen” van de machine en staat los van de opslag (harde schijf) van een apparaat. Zie het als de motor van onze virtuele instantie, waarop we ons Ubuntu Server-besturingssysteem zullen draaien. AWS verdeelt deze in afzonderlijke instantiefamilies die worden aangegeven door de letter / cijfercombinatie in de meest linkse kolom.

        De instantiefamilies hebben verschillende hardware-arrangementen, net zoals verschillende automotoren verschillende configuraties van zuigers, pluggen en brandstoffen hebben om aan verschillende eisen te voldoen. We zullen ons concentreren op twee van hun “algemene berekening” -instancefamilies, de m5 en t3.

        Ik selecteer de instantie m5.xlarge, die 4 virtuele rekenkernen (vCPU’s) en 16 GB RAM biedt. Na ongeveer een dag Ethereum 2.0-mainnet te hebben uitgevoerd, heeft mijn machine niet meer dan 4% van de beschikbare vCPU gebruikt. Zoals vermeld in het gedeelte “Future Proofing” hierboven, zullen de Ethereum 2.0-netwerkvereisten alleen maar toenemen. Maar voor de komende maanden, zonder langdurige grote netwerkpieken, zou ik hoogstwaarschijnlijk in orde zijn met een m5.large-instantie (2 virtuele kernen / vCPU’s, 8 GB RAM)

        Technische mensen met meer kennis dan ik hebben ook de t3.large-instantie aanbevolen als een redelijke optie voor Ethereum 2.0. t3.large heeft 2 vCPU’s en 8 GB geheugen, hetzelfde als m5.large, maar de t3-familie is gebouwd voor meer “burstable” netwerkactiviteit (pieken in de CPU) in plaats van de m5-familie die is gebouwd voor consistente CPU-belasting.

        Prijsstelling

        Het laatste dat u moet vermelden voordat we verder gaan met opslag, is de prijs. AWS is duur in vergelijking met andere opties zoals Digital Ocean. U betaalt afzonderlijk voor CPU (uw instantiefamilie) en opslag (uw harde schijf) op basis van wat u gebruikt. CPU wordt per uur betaald. Omdat validators 24 uur per dag online moeten zijn, kun je onderstaande prijstabel (vanaf december 2020) gebruiken om wat grove berekeningen te maken: 

        Dit zijn prijzen op aanvraag. AWS biedt wel iets genaamd Prijzen voor gereserveerde instanties, waar als u belooft een virtuele instantie van een jaar tot drie jaar te hebben, u tot 50-60% kostenverlaging kunt krijgen op de bovenstaande prijstabel. (Met dank aan Jason Chroman voor deze tip!)

        Klik op de homepage van EC2 op “Gereserveerde instanties” in het menu aan de linkerkant, zoals hieronder weergegeven:

        Klik op “Gereserveerde instantie kopen”:

        Voer in het menu dat verschijnt de details van het instantietype in en de gewenste hoeveelheid tijd om de prijzen te zien (ik kies m5.xlarge en een termijn van 36 maanden):

        Klik op “Zoeken” en bekijk de prijsopties:

        Er is een aanzienlijke korting op de prijs, meer dan 50% geloof ik, maar ik zit al drie jaar vast. Nadat u de gereserveerde instantie heeft gekocht, past AWS deze toe op een bestaande virtuele box of past deze toe zodra deze is gestart. Onthoud dat dit GEEN opslagruimte (harde schijf) omvat. 

        Opmerking: ik doe dit nog niet, omdat ik er nog niet van overtuigd ben dat AWS de beste optie is voor een individu dat één tot drie Ethereum 2.0-validatorknooppunten uitzet. Ik voer een instantie uit met on-demand-prijzen om te zien hoe deze verloopt voordat ik vastleg. 

        Opslag

        Als we teruggaan naar ons startproces voor instanties, gaan we verder naar het tabblad ‘Opslagruimte toevoegen’

        De briljante technische mensen die ik heb geraadpleegd, adviseerden een opslagcapaciteit van 100 GB General Purpose SSD. Opslag is doorgaans geen bottleneck bij Eth2-clients. Dit is echter zonder het runnen van een volledige Eth1-client. Voor Eth1-opslag zou een conservatieve schatting ongeveer 1 TB zijn. Houd hier rekening mee als u Infura niet gebruikt.

        Ik ken de eenheid in de IOPS-kolom in de bovenstaande afbeelding niet, maar het is de invoer-uitvoer voor de harde schijf die communiceert met de CPU. Dit is een klassiek knelpunt voor volledige Eth1-knooppuntsynchronisatie. Als u een volledige Eth1-client op deze computer wilt synchroniseren en u ondervindt problemen, dan is dit wellicht een plek om te zoeken.

        Poorten

        Sla ‘Tags toevoegen’ over en ga verder naar ‘Beveiligingsgroep configureren’. Dit zijn de verschillende openingen die zijn gecreëerd voor verschillende soorten inkomende en uitgaande communicatie met de instantie.

        AWS opent automatisch de traditionele SSH-poort, omdat dat de belangrijkste manier is waarop we met de instantie omgaan. Munt Cashew en Somer Esat’s uitstekende gidsen raden beide aan om wachtwoordtoegang voor SSH uit te schakelen, maar we zullen zien wanneer we de instantie starten dat dit niet de standaardoptie is voor AWS. Het is echter goed om uw SSH-poort willekeurig te verdelen in een nummer tussen 1024-65535. Dit is om te voorkomen dat kwaadwillende actoren de standaard SSH-poort via het netwerk scannen. Bekijk hoe u uw SSH-poort in het algemeen beveiligt hier en specifiek voor AWS hier.

        We moeten twee beveiligingsregels toevoegen om de Teku-client te accommoderen en het heeft te maken met peer-to-peer-communicatie. Blockchain-netwerken zijn gedecentraliseerd in de zin dat knooppunten rechtstreeks met elkaar praten. In plaats van een centraal knooppunt te raadplegen, zal een individueel knooppunt een begrip van de netwerkstatus ontwikkelen en behouden door met veel knooppunten te “roddelen”. Dit betekent dat wanneer de ene client handdrukt met de andere, ze informatie over het netwerk uitwisselen. Als je genoeg tijd hebt gedaan met verschillende knooppunten, verspreidt de informatie zich door het hele netwerk. Momenteel heeft mijn Eth2 Validator-knooppunt 74 peers waarmee het aan het chatten is.

        Teku communiceert met andere knooppunten op de 9000-poort, dus we zullen dat openstellen voor UDP en TCP, twee verschillende soorten communicatieprotocollen. 

        Daarna zou het er ongeveer zo uit moeten zien:

        SSH-sleutels en instantie starten

        Ga tot slot naar “Review and Launch”, een overzicht van de gemaakte keuzes. Na goedkeuring zal er een pop-upmenu verschijnen over SSH-sleutels. Ik laat de mijne niet zien omdat deze gevoelige informatie bevat. Namelijk het sleutelpaar dat wordt gebruikt om te authenticeren en in te loggen op de virtuele instantie via SSH (lokale opdrachtregel). Als u nog geen paar heeft, genereert AWS er ​​een voor u. U moet dit downloaden en behandelen als een privésleutel van Ethereum! Het is de enige manier om verbinding te maken met uw instantie en AWS slaat deze niet voor u op.

        Zodra alles hunky-dory is, verschijnt dit venster:

        Oke! Dat is gedaan met, laten we verder gaan met het openen en beveiligen van onze instantie en vervolgens Teku installeren en uitvoeren!

        Toegang tot instantie

        De belangrijkste manier om toegang te krijgen tot de AWS-instantie is via SSH, “Een cryptografisch protocol voor het veilig uitvoeren van netwerkdiensten via een onbeveiligd netwerk.” Zoals eerder vermeld, schakelt AWS standaard wachtwoordverificatie uit voor toegang tot de instantie. U kunt alleen het sleutelpaar gebruiken dat is gegenereerd voordat de instantie is gestart. Het sleutelpaar moet de extensie.pem hebben. 

        AWS biedt een schone manier om uw SSH-opdracht te krijgen. Als u op de actieve instantie van de hoofdpagina van EC2 klikt, ziet u een knop in de rechterbovenhoek met de tekst “verbinden”:

        Op de volgende pagina staat een SSH-opdracht die specifiek is voor uw instantie. Het zal als volgt worden gestructureerd:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [e-mail beveiligd]_IDENTIFIER.compute-ZONE.amazonaws.com

        Als u deze opdracht in een terminal invoert, begint de SSH-sessie. De eerste keer vraagt ​​de lokale machine of u de ECDSA-vingerafdruk van AWS wilt vertrouwen. Dit om een man-in-the-middle-aanval en, indien bezorgd, kan een gebruiker de vingerafdruk van zijn instantie volgen deze stappen.

        Breng in een terminal die los staat van de huidige SSH-sessie de validatorsleutelbestanden over die nodig zijn om Teku uit te voeren. In de vorige blogpost hebben we het uitzetten van 32 ETH doorlopen en validatorsleutels voor Ethereum 2.0 verkregen. Uiteindelijk bleven we achter met deze bestandsstructuur:

        eth2deposit-cli / └── validator_key_info / ├── KEYSTORE-M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        We moeten het validator_key_info-bestand overbrengen naar onze virtuele instantie. Secure Copy Protocol (scp) stelt ons in staat om dit veilig te doen. Pas de algemene scp-opdracht hieronder aan met behulp van het pad naar de bovenstaande map en de vorige SSH-opdracht:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [e-mail beveiligd]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Let op de “: ~” aan het einde van de hele opdracht.)

        U zou een bestandsoverdracht moeten zien plaatsvinden. Als je terug navigeert naar je SSH-sessie en ls intypt, zou je de overgedragen map moeten zien.

        Teku installeren

        Nu we de validatiebestanden hebben die we nodig hebben, gaan we Teku installeren. Eerst moeten we bestaande programma’s updaten en de vereiste Java-systemen installeren:

        Installeer Java

        sudo apt-update && sudo apt install default-jre && sudo apt install default-jdk

        Controleer nogmaals of de geïnstalleerde Java succesvol was met:

        java -versie

        Installeer binair

        Vind hier de laatste stabiele Teku-release. Kopieer het linkadres naar het tar.gz-bestand en download het vervolgens vanuit uw SSH-sessie. Hier is hoe de mijne eruit zag, uw versie zal hoogstwaarschijnlijk anders zijn:

        curl -JLO https://bintray.com/consensys/pegasys-repo/download_file?file_path=teku-20.11.1.tar.gz

        Decomprimeer het gedownloade bestand met de volgende opdracht. Als je een andere versie hebt, gebruik dan die bestandsnaam in plaats van teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Verwijder het bestand tar.gz omwille van de netheid.

        Na al deze stappen is dit hoe uw homedirectory eruit zou moeten zien (Teku-versienummer en inhoud kunnen verschillen:

        ubuntu / └── teku-20.11.1 / ├── LICENTIE ├── bin / ├── lib / ├── licentieafhankelijkheid.html ├── teku.autocomplete.sh └── validator_key_info / ├── KEYSTORE -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Maak een niet-rootgebruiker

        Deze stap is gekopieerd van Somer Esat’s uitstekende Ubuntu / Teku-zelfstudie

        We gaan een niet-rootgebruiker maken met de naam teku die Teku kan bedienen. Typ hieronder het volgende:

        sudo useradd –no-create-home –shell / bin / false teku 

        We gaan ook een aangepaste gegevensdirectory voor Teku maken en vervolgens de teku-gebruiker er toegang toe geven:

        sudo mkdir / var / lib / teku && sudo chown -R teku: teku / var / lib / teku

        Maak een systemd-service

        Deze stap is aangepast van Somer Esat’s uitstekende Ubuntu / Teku-zelfstudie

        Met deze stap wordt een service gemaakt waarmee Teku op de achtergrond wordt uitgevoerd. Het stelt de machine ook in staat de service automatisch opnieuw te starten als deze om de een of andere reden stopt. Dit is een noodzakelijke stap om ervoor te zorgen dat onze validator 24-7 draait.

        Maak het servicebestand met behulp van de nano-teksteditor:

        sudo nano /etc/systemd/system/teku.service

        In dit bestand (dat leeg zou moeten zijn), gaan we een reeks opdrachten invoeren die de systemd moet uitvoeren wanneer we de service starten. Hier is de onderstaande code, je moet de volgende items opgeven die we tijdens deze reis hebben verzameld:

        • Infura Eth1 HTTP-eindpunt
        • validator_key_info directorypad met twee geldige sleutelgerelateerde bestanden
        • Aangepast gegevenspad (lib / var / teku)

        Zet die waarden in de vetgedrukte code hieronder en kopieer ze allemaal naar de nano-teksteditor:

        [Eenheid] Beschrijving = Teku Beacon Node Wants = network-online.target After = network-online.target [Service] Type = simple User = teku Group = teku Restart = altijd RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku –network = mainnet –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE –validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/123456_789_ABCD. –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –data-base-path = / var / lib / teku [Installeren] WantedBy = multi-user.target

        Typ command-X en typ vervolgens “Y” om uw wijzigingen op te slaan

        We moeten “systemctl” herstarten om het bij te werken:

        sudo systemctl daemon-reload

        Start de service:

        sudo systemctl start teku

        Controleer of het goed begint:

        sudo systemctl status teku

        Als u fouten ziet, kunt u voor meer informatie het volgende uitvoeren:

        sudo journalctl -f -u teku.service

        U kunt de Teku-service stoppen door het volgende uit te voeren:

        sudo systemctl stop teku

        Kijk op de Teku-pagina voor probleemoplossing voor veelvoorkomende fouten of bekijk de Teku-onenigheid, die wordt gecontroleerd door het team.

        Zodra u denkt dat alles is gladgestreken, schakelt u de service in om opnieuw te starten als deze wordt afgesloten door het volgende uit te voeren:

        sudo systemctl enable teku

        Daar heb je het! Het zou nu moeten koken. Wanneer u de Teku-service inspecteert, ziet u een reeks logboeken die een synchronisatiegebeurtenis vermelden; dit is uw validator die de bakenketen synchroniseert. Zodra het de kop bereikt, veranderen die logboeken in Slot Event en zie je ook je attestprestaties en blokvoorstellen.

        Lancering

        Bron: Beaconcha.in

        Op 1 december om 12 uur UTC werden de eerste blokken van de Beacon Chain gevalideerd. Het eerste blok kwam uit Validator 19026, met de raadselachtige graffiti: “Mr F was here.” Twaalf seconden later kwam het volgende blok, graffiti die aangeeft dat de validator zich mogelijk in bevindt Zug, Zwitserland. De Eth2 Beacon Chain groeide gestaag, blok voor blok elke 12 seconden. Toen kwam de volgende hindernis: zouden er genoeg validators online zijn om de eerste Epoch af te ronden? Ja! 82,27% van de validators bevestigde de geldigheid van Epoch 0, de spreekwoordelijke begane grond van de Beacon Chain. U kunt hier meer lezen over de lancering van Beacon Chain en wat er hierna komt. 

        Bron: Beaconcha.in

        We zitten nu in Epoch 760, wat betekent dat de Beacon Chain al bijna een week soepel loopt. 

        Hier is een opname vanuit mijn perspectief van het ontstaansmoment, met behulp van de opstelling die in dit bericht wordt beschreven:

        In de volgende aflevering zullen we een samenvatting geven van hoe het gaat. Ik ga toegang krijgen tot de statistieken van Teku, bespreek de kosten van het uitvoeren van AWS en bespreek kort de staat van het netwerk.

        Blijf kijken!

        Bronnen en links

        Met dank aan James Beck, Meredith Baxter, Jason Chroman, Aaron Davis, Chaminda Divitotawela, Ben Edgington, The Dark Jester, Somer Esat, Joseph Lubin, Collin Meyers, Nick Nelson, Mara Schmiedt, Adrian Sutton en Alex Tudorache voor ondersteuning en technische assistentie.

        Ethereum 2.0 Nieuwsbrief Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.

        Mike Owergreen Administrator
        Sorry! The Author has not filled his profile.
        follow me
        Like this post? Please share to your friends:
        Adblock
        detector
        map