Min reise til å bli validator på Ethereum 2.0, del 2

blogg 1NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPressNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogDevelopers

Min reise til å bli validator på Ethereum 2.0, del 2

Hva er noen ting du bør vurdere når du velger maskinvare og programvare for å kjøre en Ethereum 2.0 validator-klient? Av Coogan Brennan 5. desember 2020 Publisert 5. desember 2020

Min reise til å bli validator på Ethereum 2 0 Del 2

Merk: Du kan fortsatt bli validator på Ethereum 2.0-nettverket! Ventetid for å bli aktivert som validator – fra 4. desember 2020 er ventetiden omtrent 9,9 dager. Se trinnene for innsats i del 1 i denne serien.

  1. Ansvarsfraskrivelse
  2. Introduksjon
  3. Valideringskonfigurasjonshensyn
  1. Fremtidig korrekturvare
  2. Å kjøre eller ikke kjøre en Eth1-klient?
  3. Virtuelt mot lokalt vertskap
  4. Eth2-klientvalg og unngå straffer
  • Sette opp AWS-forekomst
    1. Operativsystem
    2. Priser
    3. Oppbevaring
    4. Porter
    5. SSH-nøkler og Instanslansering
    6. Installere Teku
      1. Krav
      2. Installer binær
      3. Opprett ikke-rotbruker
      4. Opprett systemtjeneste
      5. Start
      6. Ansvarsfraskrivelse

        Dette er et innlegg jeg skriver som ansatt i ConsenSys og noen som planlegger å satse på fyrkjeden. Den tidligere uttalelsen betyr at jeg prioriterer ConsenSys-produkter (ConsenSys-produkter er vanligvis best i klassen for Ethereum, og jeg har også tilgang til ingeniørteam som kan hjelpe meg med å svare på spørsmål og feilsøke). Sistnevnte uttalelse betyr at jeg optimaliserer for pris og brukervennlighet: Jeg har ikke tusenvis av ETH for å gi betydelige belønninger, så jeg tar noen snarveier. Dette er beslutninger jeg har tatt for å gjøre innsatsen til Ethereum 2.0 så enkel og tilgjengelig for enkeltpersoner som mulig, men kommer med avveininger til desentralisering og personvern. Du kan imidlertid følge de brede strøkene i opplæringen nedenfor og ta forskjellige valg. Faktisk, hvis du kan gjøre det, vil jeg oppfordre deg til å gjøre det! 

        Sist, innsats i Ethereum 2.0 er veldig eksperimentell og involverer langsiktig forpliktelse (jeg tildeler tre år). Vennligst ikke delta hvis du ikke er komfortabel med det høye risikonivået med noe som fortsatt er under utvikling. Hvis du er usikker på om du skal satse, kan du bli med i ConsenSys uenighet og spør i # teku-public channel. 

        Introduksjon

        I forrige innlegg diskuterte vi årsakene til utplasseringen av Ethereum 2.0 og gikk gjennom innsatsen 32 ETH i Ethereum 1.0-innskuddskontrakten. Vi berørte nøkkelgenerering og hvordan innsatsprosessen fortsetter Launchpad kobler Ethereum 1.0 til 2.0.

        23. november ble minimumsmengden av innsatt ETH for å lansere Ethereum 2.0 – omtrent 524,288 – oppfylt. Folk kan fortsette å satse på kontrakten, og antallet validatorer har steget til over 33 000 per 4. desember.

        MetaMask’s Aaron Davis deler tankene sine i den interne ConsenSys Slack-innsatskanalen 

        Selv om det var ekstremt spennende å komme inn i Genesis-blokken som validator, hadde jeg sekunder senere en lignende opplevelse som min kollega Aaron Davis i vår interne ConsenSys-innsatskanal: For hvilken gal oppgave hadde jeg registrert meg? Heldigvis har jeg tilgang til utrolig strålende og tekniske folk som er veldedige nok til å gi denne rube noen tips, tips og innsikt om å kjøre stakinginfrastruktur. Jeg håper å formidle en brøkdel av det verdifulle rådet her til andre interesserte parter.

        Det er hva den første delen av denne artikkelen vil være: Hva er noen ting du bør vurdere når du velger maskinvare og programvare for å kjøre en Ethereum 2.0 validator-klient? Den andre delen vil gå gjennom den spesifikke maskinvare / programvarekombinasjonen jeg har valgt for min validator-klient. Valgene du tar for konfigurasjonen din, vil avhenge av ressursene, den personlige tilbøyeligheten og den tekniske kapasiteten. Jeg vil gjøre mitt beste for å fremheve hvordan personlige skjevheter og omstendigheter informerte valgene mine.

        Sist, før vi hopper inn i det, vil jeg gjenta disse innleggene er nesten som journaloppføringer for min erfaring med å sette 32 ETH (om enn journaloppføringer med omfattende tekniske sider). Som sådan kan jeg endre tilnærmingen litt etter hvert som fyrkjeden skrider frem. For eksempel gikk jeg inn og tenkte at jeg definitivt ville bruke AWS. Som du vil lese nedenfor, vurderer jeg det på nytt. Jeg kommer også til å være veldig klar over det økonomiske elementet i innsatsen. Staking er en måte å støtte Ethereum-økosystemet på, men for bærekraftig offentlig bruk bør det også være tilgjengelig for og mulig for folk som har ETH til å gjøre det. 

        Fremtidig korrekturvare

        De grunnleggende kravene for å kjøre en validator i dag er relativt enkle å tilfredsstille. Mara Schmiedt og Collin Meyers ’ Valideringsveiledning på Bankless har en god oversikt over minimumskrav. Det mest utfordrende aspektet ved å bestemme Ethereum 2.0-valideringsutstyr er å balansere dagens behov i Beacon Chain Phase 0 med fremtidige ukjente krav når utviklingen fortsetter. (Dette er ikke en bekymring hvis du er komfortabel med å følge nøye med på validatoren din og i stand til raskt og enkelt å takle endringer) 

        Ben Edgington, Teku prosjektleder og utgiver av Eth2.news, ga meg noen kanttilfeller der nettverket kan kreve mer av validatorklienten. På kort sikt vil den største bekymringen være noe sånt hendelsen med Medalla tidsserver, der en feil og påfølgende løsning i Prysm-klienten stoppet sluttbehandlingen på testnettet (grovt sett kunne ikke nettverket “produsere blokker”). Siden det ikke var noen endelighet på nettverket (ingen “bekreftede blokker”), måtte validatorer holde mange flere transaksjoner i RAM-en enn vanlig. 

        Maskiner med 8 GB RAM – som ville ha vært mer enn nok under normale omstendigheter – begynte å støte på “lite minne” problemer som kan ha ført til kutt. En pigg som denne, selv om den er uvanlig, er ikke uaktuelt for fase 0-mainnet.

        Fremtidige konfigurasjons-uklarheter for nettverket er sammenslåing av Ethereum 1.0 og 2.0 og innføring av skjæring. Vi vet fortsatt ikke når disse sammenslåingene vil skje eller nøyaktig hva de vil kreve. Jeg vil gjerne ha en sterk CPU-ryggrad som går inn i fase 0 (4 virtuell kjerne, 16 GB RAM med 100 GB SSD), og deretter fokusere oppmerksomheten min for fremtidige justeringer rundt lagringsplass (etterlater wiggle rom her). Vær oppmerksom på at dette kan vise seg å være for mye og spiser store belønninger.

        Dette er fremtidens “kjente ukjente”, la oss diskutere hovedkonfigurasjonspunktene for validatorer i dag.

        Å kjøre eller ikke kjøre en Eth1-klient?

        Det er en overgangsritual jeg prøver å underkaste bootcamp-studentene våre så ofte som mulig: Synkronisering av en Ethereum 1.0-klient. Det er en åpen hemmelighet som faktisk er vert for en “full” Ethereum 1.0-node er en handling av kjærlighet snarere enn en herdet, Fangens dilemma-løsning. “Full” må settes i anførselstegn fordi selv Ethereum-kjerneutviklere har vanskelig for å bli enige om en definisjon av hva “full node” egentlig betyr.

        En ting vi alle kan være enige om: Det tar mer tid og lagring å synkronisere en Ethereum 1.0-klient enn du skulle forestille deg. Validatorene våre må ha en måte å spørre Ethereum 1.0-nettverksdatabasen (vi kommer nærmere inn på hvorfor litt senere). Hvis du vil spare plass og hodepine ved synkronisering lokalt, kan du bruke et Infura-sluttpunkt, som er tilgjengelig gratis ved registrering. 

        Selv om dette sparer betydelig lagring og logistisk bekymring, ofrer det en viss desentralisering for Eth1- og Eth2-nettverket samtidig. Hvis Infura skulle gå ned, som er ekstremt sjelden, men som forekommer, som ville forårsake en ringeffekt på tvers av Ethereum 2.0-validatorene som bruker den til Ethereum 1.0-endepunktet. Noe å vurdere!

        (Bare for å være klar: Vanskeligheten med å synkronisere en Ethereum-full node har å gjøre med naturen til Ethereum-verdensstaten, ikke med Ethereum 1.0-kjerneutviklerne som har gjort en fantastisk jobb med å takle dette ekstremt utfordrende problemet.)

        Virtual vs Local Hosting

        Den neste vurderingen for meg var å være vert for en valideringsnode lokalt (hjemme hos meg) eller virtuelt (hos en virtuell tjenesteleverandør som Amazon Web Services (AWS), Digital Ocean, etc.). Som jeg nevnte i forrige stykke, stoler jeg ikke på meg selv til å kjøre en konsistent validatorknute hjemmefra, selv på en gammel bærbar datamaskin som er lagret et sted. Klønete og klønete, jeg vil enten sparke den over eller glemme det.

        Jeg velger å kjøre min node på AWS fordi det er det jeg er mest kjent med (Etter å ha gått gjennom hele prosessen, gjetter jeg imidlertid denne avgjørelsen. Jeg vil diskutere dette senere). Avveien her er igjen desentralisering: Hvis AWS går ned eller har problemer (som det gjorde nylig), Jeg er prisgitt dem. Hvis nok folk kjører noder på AWS, kan det påvirke det større Ethereum-nettverket.

        Folk vil sannsynligvis velge selv for denne. Lokal hosting er en spesiell type prosjekt, og ikke alle har tid, ressurser eller engasjement som kreves. Mens virtuell hosting er en sentraliserende kraft, velger jeg å gå med den på grunn av dens brukervennlighet og (forhåpentligvis) garantert oppetid. 

        Hvis du vil kjøre en valideringsnode lokalt, kan du fortsatt følge den generelle retningen i denne opplæringen, Somer Esats utmerkede serie opplæringsprogrammer med forskjellige klienter eller til og med synkronisere en Raspberry Pi Model 4B med 8 GB RAM med Ethereum på ARM. (Synkronisering på Raspberry Pi er fortsatt veldig eksperimentell, og folk bør vente til Ethereum på ARM-teamet bekrefter stabiliteten)

        Eth2-klientvalg og unngå straffer

        Et annet stort valg er Ethereum 2.0-klienten blant eksisterende kunder: fyr, Lodestar, Nimbus, Prysm og Teku. Jeg er sterkt partisk mot Teku og ikke kløktig nok til å diskutere kundenes finere poeng. denne artikkelen er en anstendig oversikt over klientens ytelse på Medalla. (Husk at Medalla krevde mye mer fra prosessorer enn Mainnet vil.)

        Proof of Stake inneholder eksplisitte motiver for å oppmuntre til riktig oppførsel i nettverket. Disse har form av dinging validatorer for å være frakoblet, og det mer dramatiske trekket av å kutte aktører for å iverksette ondsinnede handlinger mot nettverket, bevisst eller på annen måte.

        Det vanligste problemet er å sørge for at validatoren din er tilgjengelig for nettverket. Dette betyr å sørge for at validatoren din er online. Det er DevOps-tilnærmingen til dette problemet – å lage overvåkings- og varslingssystem for å varsle deg hvis validatoren din går offline – som jeg ikke vil dekke her.

        Men det er en annen måte å være utilgjengelig for nettverket, og det er hvis klienten begynner å oppføre seg dårlig av en eller annen grunn. Etter tidsserverfeilen forårsaket en nettverksnedgang på Medalla, kom Eth2-kjerneutviklere sammen for å utvikle seg “[A] standardformat for overføring av signaturloggen til en nøkkel gjør at validatorer enkelt kan bytte mellom klienter uten risiko for signering av motstridende meldinger.” Ikke alle klienter har denne beskyttelsen, men Teku har det. Her kan du lese om hvordan du bruker Teku’s Slash Protection (kjører som standard), inkludert migrering mellom Teku-noder eller en ikke-Teku til Teku-node..

        Hvis du har problemer med klienten din og trenger å starte hele nettverket på nytt, må du være oppmerksom på svak subjektivitet. Proof of Work tillater alle å gå tilbake til opprinnelsesblokken til nettverket og tillitsløst bygge nettverkstilstanden fra bunnen av. Proof of Stake har imidlertid en fangst i den forbindelse: Hvis en tredjedel av nettverksvalidatorene på et bestemt punkt går ut, men fortsatt fortsetter å signere blokker og attest, kan de endre nettverkstilstanden og mate falske data til en node som synkroniseres til nettverk hvis de ondsinnede aktørene fanger synkroniseringsnoden før synkroniseringsnoden når hvor validatorene trakk pengene sine. Du kan lese mer om det her, men det korte svaret er at du må ha et “svakt subjektivitetskontrollpunkt” eller en kodet tilstandsfil, egentlig et arkiv over nettverket. Teku tilbyr oppstartsflagg for begge.

        Den siste straffesaken er den mest alvorlige: Slashing. Slashing oppstår når en staker jobber mot reglene i nettverket. Det er forskjellig fra å bli straffet fra å være frakoblet. Det arbeides aktivt mot nettverket ved å sende inn motstridende valideringsinformasjon. Det er noen virkelig gode materialer for å lære mer om å kutte og hvordan du kan forhindre det:

        Hovedtaket er å ikke kjøre en valideringsnøkkel på flere klienter. Tilsynelatende er det dette som forårsaket den første skjærende hendelsen noensinne, som skjedde 2. des. Det har vært en del skråstrekk siden! Hvis du migrerer fra en forekomst til en annen, må du sjekke om du ikke har to maskiner som arbeider med samme nøkkel:

        Papa Ben forteller det som det er. Kilde

        AWS + Infura + Teku Validator Configuration Specs

        Mitt Genesis-blokkeringsoppsett:

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

        Prosessor: Intel Xeon Platinum 8000-prosessor, 3,1 GHz. (Amazon Web Service)

        Hukommelse: 4 virtuelle kjerner, 16 GB RAM (Amazon Web Service)

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

        Ethereum 1.0-klient: Infura endepunkt (gratis nivå)

        Ethereum 2.0-klient: Teku

        Gjennom å se på alle ovennevnte hensyn var jeg usikker på den beste tilnærmingen til å bygge et validatoroppsett. For meg selv vil jeg velge en maskin og generelt ikke bekymre meg for å bytte den i minst to år. Dette hjelper med de totale valideringskostnadene (jeg kan få en betydelig rabatt ved å låse meg hos en virtuell leverandør i noen år), og jeg er ikke spesielt smidig med å spinne opp servere. Denne framtidssikrede eller “over-spec’ing” tilnærmingen gjør forhåpentligvis livet mitt de neste to årene litt lettere.

        Opprinnelig var jeg sikker på at AWS var den beste virtuelle plattformen, og det er tjenesten jeg vil bruke for dette innlegget og det neste. Etter å ha gått gjennom hele prosessen skjønte jeg imidlertid at AWS kan være for mye for den enkelte utvikleren. AWS ‘virkelige styrke ser ut til å være kapasiteten til å dynamisk oppskalere for å imøtekomme etterspørsel som koster ekstra. Dette gir økonomisk mening for et storskala prosjekt på bedriftsnivå, men individuell Ethereum 2.0 strøm kundens krav krever ikke slik strenghet.

        Jeg kommer til å fortsette med AWS, men underholder også muligheten til å kjøre en forekomst på Digital Ocean, noe som kan være mer passende for en enkelt utvikler. Mer om det på et senere tidspunkt.

        Sett opp Infura-konto

        Jeg velger å bruke Infura som Ethereum 1.0-sluttpunkt. For nå ser fyrkjeden innskuddskontrakten på Ethereum 1.0 for å aktivere nye spillere når de riktig har deponert 32 ETH og sendt inn passende BLS-signaturer..

        I fremtiden vil fyrkjeden begynne å teste videre behandling ved å begynne å bruke tilstandsinformasjon fra Ethereum 1.0 for å opprette parallelle kontrollpunkter på fyrkjeden..

        Som vi nevnte ovenfor, er det to hovedmåter å ha synlighet til Ethereum 1.0-nettverket. Den ene er å synkronisere og aktivt vedlikeholde en Ethereum 1.0-node, som skaper en lokal Ethereum 1.0-statusdatabase. Den andre er å bruke en tjeneste som Infura, som gir et enkelt Ethereum 1.0-endepunkt, tilgjengelig via HTTPS eller WebSockets.

        Logg på en konto her. Når du har en konto, klikker du på Ethereum-logoen på venstre side.

        Klikk “Opprett nytt prosjekt” i øvre høyre hjørne

        Gi prosjektet ditt navn (mitt er “Eth 2 Validator”), og gå til “Innstillinger”, sørg for at nettverksendepunktene dine er “Mainnet” og kopier HTTPS-endepunktet:

        Vi bruker dette senere for oppstartskommandoen for Teku-klienten!

        Sette opp AWS-forekomst

        Å sette opp en EC2-forekomst på Amazon er rett fram. Vi vil ha noen få justeringer her og der for å hjelpe den virtuelle forekomsten vår til å spille bra med Teku.

        Opprett en AWS-konto (forskjellig fra en Amazon.com-konto) og logg inn på AWS-konsollen. Gå til EC2-siden, som vil se ut slik:

        Klikk på “Launch Instance” -knappen. Deretter ser du følgende skjermbilde:

        Operativsystem

        Det er her vi velger hvilket maskinbilde (som jeg tenker på som et operativsystem) vi vil bruke på vår virtuelle forekomst. Jeg velger Ubuntu Server 20.04, som er et Linux-basert servermiljø. Ubuntu Server-miljøet har noen få viktige optimaliseringsforskjeller fra Ubuntu Desktop-miljøet. Hovedforskjellen for våre formål er at Ubuntu Server mangler et grafisk brukergrensesnitt (GUI). Hvor vi skal, det er bare en kommandolinje! Bringer meg tilbake til Apple II-dagene mine.

        Etter å ha valgt operativsystemet vårt, velger vi deretter vår forekomsttype:

        Jeg synes denne menyen er ganske overveldende, så jeg kommer til å bryte den litt ned for deg. Her velger vi databehandlingskjerne / RAM-effekt / CPU for maskinen vår. Det er “rå” eller “aktivt minne” på maskinen og atskilt fra lagring (harddisk) på en enhet. Tenk på det som motoren til vår virtuelle forekomst, som vi skal kjøre operativsystemet Ubuntu Server på. AWS skiller disse inn i separate forekomstfamilier betegnet med bokstav / tallkombinasjon lengst til venstre kolonne.

        Forekomstfamiliene har forskjellige maskinvarearrangementer, akkurat som forskjellige bilmotorer har forskjellige konfigurasjoner av stempler, plugger og drivstoff for å møte forskjellige krav. Vi vil fokusere på to av deres “generelle beregnings” -instansfamilier, m5 og t3.

        Jeg velger forekomsten m5.xlarge, som gir 4 virtuelle databehandlingskjerner (vCPUer) og 16 GB RAM. Etter å ha kjørt Ethereum 2.0 mainnet i en dag eller så, har ikke maskinen min brukt mer enn 4% av tilgjengelig vCPU. Som nevnt i delen “Future Proofing” ovenfor, vil kravene til Ethereum 2.0-nettverket bare vokse. Men de neste månedene, uten noen langvarige store nettverkspikes, ville jeg mest sannsynlig ha det bra med en m5.large forekomst (2 virtuelle kjerner / vCPUer, 8 GB RAM)

        Tekniske folk som er mer kunnskapsrike enn meg selv, har også anbefalt t3.large-forekomsten som et rimelig alternativ for Ethereum 2.0. t3.large har 2 vCPUer og 8 GB minne, samme som m5.large, men t3-familien er bygget for mer “sprengbar” nettverksaktivitet (pigger i CPU) i stedet for m5-familien bygget for jevn CPU-belastning.

        Priser

        Den siste tingen å nevne før vi går over til lagring er pris. AWS er ​​dyrt sammenlignet med andre alternativer som Digital Ocean. Du betaler for CPU (din forekomsten familie) og lagring (harddisken) separat basert på hva du bruker. CPU betales per time. Siden validatorer må være online 24 timer, kan du bruke pristabellen nedenfor (fra desember 2020) for å gjøre noen grove beregninger: 

        Dette er priser på forespørsel. AWS gir noe som heter Reservert pris for øyeblikk, der hvis du lover å ha en virtuell forekomst fra et år til tre år, kan du få opptil 50-60% kostnadsreduksjon på ovenstående pristabell. (Takk til Jason Chroman for dette tipset!)

        Fra EC2-hjemmesiden klikker du på “Reserverte forekomster” i menyen til venstre, vist nedenfor:

        Klikk på “Kjøp Reservert Forekomst”:

        I menyen som dukker opp, legg inn informasjon om forekomststypen og hvor lang tid det er å se priser for (jeg velger m5.xlarge og en periode på 36 måneder):

        Klikk “Søk” og se prisalternativene:

        Det er en betydelig prisrabatt, over 50% tror jeg, men jeg er låst inne i tre år. Når du har kjøpt den reserverte forekomsten, bruker AWS den på en eksisterende virtuell boks eller vil bruke den når den er lansert. Husk at dette IKKE inkluderer lagringsplass (harddisk). 

        Merk: Jeg gjør ikke dette ennå, da jeg ennå ikke er overbevist om at AWS er ​​det beste alternativet for en person som setter en til tre Ethereum 2.0-valideringsnoder. Jeg kjører en forekomst med on-demand priser for å se hvordan det går før jeg forplikter meg. 

        Oppbevaring

        Når vi går tilbake til vår lanseringsprosess, går vi videre til fanen “Legg til lagring”

        De strålende tekniske personene jeg konsulterte, anbefalte en lagringsmengde på 100 GB SSD. Lagring er vanligvis ikke en flaskehals med Eth2-klienter. Dette er imidlertid uten kjører en full Eth1-klient. For lagring av Eth1 vil et konservativt guestestimate være omtrent 1 TB. Husk å gjøre rede for dette hvis du ikke bruker Infura.

        Jeg kjenner ikke enheten i IOPS-kolonnen i bildet ovenfor, men det er inngangsutgangen for harddisken som kommuniserer med CPUen. Dette er en klassisk flaskehals for full synkronisering av Eth1-noder. Hvis du ønsker å synkronisere en full Eth1-klient på denne maskinen og har problemer, kan dette være et sted å se.

        Porter

        Gå til “Legg til tagger” og gå videre til “Konfigurer sikkerhetsgruppe.” Dette er de forskjellige åpningene som er opprettet for forskjellige typer innkommende og utgående kommunikasjon med forekomsten.

        AWS åpner automatisk den tradisjonelle SSH-porten, da det er den viktigste måten vi vil samhandle med forekomsten på. Mynt Cashew og Somer Esat’s gode guider anbefaler at du deaktiverer passordtilgang for SSH, men vi ser når vi starter forekomsten som ikke er standardalternativet for AWS. Det er imidlertid bra å randomisere SSH-porten til et tall mellom 1024-65535. Dette er for å forhindre at ondsinnede aktører nettverksskanner standard SSH-port. Se hvordan du sikrer SSH-porten generelt her og spesielt for AWS her.

        Vi må legge til to sikkerhetsregler for å imøtekomme Teku-klienten, og det har å gjøre med peer-to-peer-kommunikasjon. Blockchain-nettverk er desentraliserte i den forstand at noder snakker direkte til hverandre. I stedet for å konsultere en sentral node, vil en individuell node utvikle og opprettholde en forståelse av nettverkstilstanden ved å “sladre” med mange noder. Dette betyr at når en klient håndtrykker med en annen, bytter de informasjon om nettverket. Gjort nok ganger med forskjellige noder, og informasjon forplanter seg i hele nettverket. For øyeblikket har Eth2 Validator-noden 74 jevnaldrende som den chatter med.

        Teku kommuniserer med andre noder på 9000-porten, så vi åpner det for UDP og TCP, to forskjellige typer kommunikasjonsprotokoller. 

        Etterpå skal det se ut slik:

        SSH-nøkler og Instanslansering

        Gå sist til “Review and Launch”, en oversikt over valgene du har gjort. Når det er godkjent, vil det være en lokalmeny om SSH-taster. Jeg viser ikke min fordi den inneholder sensitiv informasjon. Tastaturet brukes nemlig til å autentisere og logge på den virtuelle forekomsten via SSH (lokal kommandolinje). Hvis du ikke allerede har et par, genererer AWS et for deg. Du må laste ned dette og behandle det som en privat Ethereum-nøkkel! Det er den eneste måten å koble til forekomsten din, og AWS lagrer den ikke for deg.

        Når alt er hunky-dory, vil dette vinduet vises:

        Greit! Det er gjort med, la oss gå videre til å få tilgang til og sikre forekomsten vår, og deretter installere og kjøre Teku!

        Få tilgang til Instance

        Den viktigste måten å få tilgang til AWS-forekomsten er gjennom SSH, “En kryptografisk protokoll for drift av nettverkstjenester sikkert over et usikret nettverk.” Som nevnt tidligere, deaktiverer AWS som standard passordgodkjenning for tilgang til forekomsten. Du kan bare bruke tastaturet som er generert før forekomsten startes. Tastaturet skal ha en.pem-fil. 

        AWS gir en ren måte å få SSH-kommandoen din på. Når du klikker på den løpende forekomsten fra EC2-hovedsiden, er det en knapp øverst til høyre som sier “koble til”:

        På neste side vil det være en SSH-kommando som er spesifikk for din forekomst. Det vil være strukturert slik:

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

        Å legge inn denne kommandoen i en terminal vil starte SSH-økten. Første gang vil den lokale maskinen spørre om du vil stole på ECDSA-fingeravtrykket fra AWS. Dette er for å forhindre a mann-i-midten-angrep og hvis det er bekymret, kan en bruker få forekomstens fingeravtrykk etter disse trinnene.

        I en terminal som er skilt fra den gjeldende SSH-økten, overfører du valideringsnøkkelfilene som trengs for å kjøre Teku. I forrige blogginnlegg gikk vi gjennom å sette 32 ETH og skaffe valideringsnøkler for Ethereum 2.0. På slutten satt vi igjen med denne filstrukturen:

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

        Vi må overføre validator_key_info-filen til vår virtuelle forekomst. Secure Copy Protocol (scp) tillater oss å gjøre dette sikkert. Tilpass den generiske scp-kommandoen nedenfor ved å bruke banen til katalogen ovenfor og den forrige SSH-kommandoen:

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

        (Merk “: ~” på slutten av hele kommandoen.)

        Du bør se at en filoverføring skjer. Hvis du navigerer tilbake til SSH-økten og skriver inn ls, bør du se den overførte katalogen.

        Installere Teku

        Nå som vi har validatorfilene vi trenger, skal vi installere Teku. Først må vi oppdatere eksisterende programmer og installere de nødvendige Java-systemene:

        Installer Java

        sudo apt oppdatering && sudo apt installer standard-jre && sudo apt installer standard-jdk

        Dobbeltsjekk Java installert var vellykket med:

        java -versjon

        Installer binær

        Finn den siste stabile Teku-utgivelsen her. Kopier lenkeadressen til tar.gz-filen, og last den deretter ned fra SSH-økten. Slik så min ut, din versjon vil sannsynligvis være annerledes:

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

        Komprimer den nedlastede filen med følgende kommando. Hvis du har en annen versjon, kan du sende inn filnavnet i motsetning til teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Fjern ren tar.gz-filen for renhets skyld.

        Etter alle disse trinnene, her er hvordan hjemmekatalogen din skal se ut (Teku versjonsnummer og innhold kan være annerledes:

        ubuntu / └── teku-20.11.1 / ├── LISENS ├── bin / ├── lib / ├── lisensavhengighet.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

        Opprett en ikke-rotbruker

        Dette trinnet er kopiert fra Somer Esat’s utmerket Ubuntu / Teku tutorial

        Vi skal opprette en ikke-rotbruker som heter teku som kan betjene Teku. Skriv inn følgende nedenfor:

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

        Vi skal også lage en tilpasset datakatalog for Teku, og deretter gi teku-brukeren tilgang til den:

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

        Opprett systemtjeneste

        Dette trinnet er tilpasset Somer Esat’s utmerket Ubuntu / Teku tutorial

        Dette trinnet vil lage en tjeneste som kjører Teku i bakgrunnen. Det vil også tillate maskinen å starte tjenesten automatisk hvis den av en eller annen grunn stopper. Dette er et nødvendig trinn for å sikre at validatoren vår kjører 24-7.

        Opprett servicefilen ved hjelp av nano-teksteditoren:

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

        I denne filen (som skal være tom) skal vi legge inn en serie kommandoer som systemd skal utføre når vi starter tjenesten. Her er koden nedenfor, du må legge inn følgende elementer som vi har samlet gjennom denne reisen:

        • Infura Eth1 HTTP-endepunkt
        • validator_key_info katalogbane med to gyldige nøkkelrelaterte filer
        • Tilpasset datasti (lib / var / teku)

        Sett disse verdiene i fet skrift nedenfor, og kopier det hele inn i nano-teksteditoren:

        [Enhet] Beskrivelse = Teku Beacon Node Ønsker = nettverk-online.target Etter = nettverk-online.target [Service] Type = enkel bruker = teku Group = teku Restart = alltid RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku – nettverk = 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/KEYSTORE- –rest-api-enabled = true –rest-api-docs-enabled = true – metrics-enabled –validators-keystore-locking-enabled = false –data-base-sti = / var / lib / teku [Installer] WantedBy = multi-user.target

        Skriv command-X, og skriv deretter “Y” for å lagre endringene

        Vi må starte “systemctl” på nytt for å oppdatere det:

        sudo systemctl daemon-reload

        Start tjenesten:

        sudo systemctl start teku

        Kontroller at det begynner å gå bra:

        sudo systemctl status teku

        Hvis du ser noen feil, kan du få mer informasjon ved å kjøre:

        sudo journalctl -f -u teku.service

        Du kan stoppe Teku-tjenesten ved å kjøre:

        sudo systemctl stopp teku

        Sjekk Teku feilsøkingsside for vanlige feil eller sjekk Teku-uoverensstemmelsen, som overvåkes av teamet.

        Når du føler at du har stryket ting, kan du aktivere tjenesten på nytt hvis den slås av ved å kjøre:

        sudo systemctl aktiver teku

        Der har du det! Ting burde lage mat akkurat nå. Når du inspiserer Teku-tjenesten, vil du se en serie logger som noterer seg en synkroniseringshendelse, dette er validatoren din som synkroniserer fyrkjeden. Når den når hodet, vil disse loggene endres til å lese Slot Event, og du vil også se attestasjonsytelsen og blokkere forslag.

        Start

        Kilde: Beaconcha.in

        1. desember klokka 12 UTC ble Beacon Chain’s første blokker validert. Den første blokken kom fra Validator 19026, med den gåtefulle graffiti, “Mr F var her.” Tolv sekunder senere kom neste blokk, graffiti som indikerer at validatoren kan være lokalisert i Zug, Sveits. Eth2 Beacon Chain vokste jevnt, blokk for blokk hvert 12. sekund. Så kom neste hindring: ville nok validatorer være online for å fullføre den første epoken? Ja! 82,27% av validatorene bekreftet gyldigheten til Epoch 0, den ordspråklige første etasje i Beacon Chain. Du kan lese mer om lanseringen av Beacon Chain, og hva som er neste, her. 

        Kilde: Beaconcha.in

        Vi er nå på Epoch 760, noe som betyr at Beacon Chain har gått jevnt i nesten en uke. 

        Her er et skudd fra mitt perspektiv på opphavsmomentet, ved hjelp av oppsettet som er beskrevet i dette innlegget:

        I neste avtale tar vi en oversikt over hvordan ting går. Jeg kommer til å få tilgang til beregningene fra Teku, diskutere kostnadene ved å kjøre AWS, og kort diskutere tilstanden til nettverket.

        Følg med!

        Ressurser og lenker

        Takk til 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 og Alex Tudorache for støtte og teknisk assistanse.

        Ethereum 2.0 Nyhetsbrev Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser og mer.

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