Matkani vahvistajaksi tulemiseen Ethereum 2.0, osa 2

blogi 1NewsDevelopersEnterpriseBlockchain ExplainedTapahtumat ja konferenssitPainaUutiskirjeet

tilaa uutiskirjeemme.

Sähköpostiosoite

Kunnioitamme yksityisyyttäsi

EtusivuBlogiKehittäjät

Matkani vahvistajaksi tulemiseen Ethereum 2.0, osa 2

Mitä asioita sinun tulisi ottaa huomioon, kun valitset laitteita ja ohjelmistoja Ethereum 2.0 -validointiasiakkaan suorittamiseksi? Lähettäjä Coogan Brennan 5. joulukuuta 2020 Lähetetty 5. joulukuuta 2020

Matkani tulla validoijaksi Ethereum 2 0 -osassa 2

Huomaa: Voit silti tulla validoijaksi Ethereum 2.0 -verkossa! Odotusaika aktivoidaan validoijaksi – 4. joulukuuta 2020 alkaen odotusaika on karkeasti 9.9 päivää. Katso panostamisen vaiheet tämän sarjan osasta 1.

  1. Vastuuvapauslauseke
  2. Johdanto
  3. Validatorin määritysnäkökohdat
  1. Tulevaisuuden todentamislaitteet
  2. Eth1-asiakkaan suorittaminen tai ei suorittaminen?
  3. Virtuaalinen vs. paikallinen isännöinti
  4. Eth2-asiakkaan valinta ja rangaistusten välttäminen
  • AWS-ilmentymän määrittäminen
    1. Käyttöjärjestelmä
    2. Hinnoittelu
    3. Varastointi
    4. Portit
    5. SSH-avaimet ja ilmentymien käynnistys
    6. Tekun asentaminen
      1. Vaatimukset
      2. Asenna binaarinen
      3. Luo ei-root-käyttäjä
      4. Luo systemd-palvelu
      5. Tuoda markkinoille
      6. Vastuuvapauslauseke

        Tämä on viesti, jonka kirjoitan ConsenSysin työntekijänä ja joku, joka aikoo osallistua majakkaketjuun. Edellinen lausunto tarkoittaa, että priorisoin ConsenSys-tuotteet (ConsenSys-tuotteet ovat tyypillisesti Ethereumin parhaita luokkia, ja minulla on myös pääsy suunnittelutiimeihin, jotka voivat auttaa minua vastaamaan kysymyksiin ja vianetsintään). Viimeksi mainittu väite tarkoittaa, että optimoin kustannusten ja helppokäyttöisyyden kannalta: Minulla ei ole tuhansia ETH: ta tuottamaan merkittäviä etuja, joten otan joitain pikavalintoja. Nämä ovat päätöksiä, joiden tarkoituksena on tehdä Ethereum 2.0: sta panostus mahdollisimman suoraviivaiseksi ja saataville yksityishenkilöille, mutta niihin liittyy kompromisseja hajauttamiseen ja yksityisyyteen. Voit kuitenkin seurata alla olevan opetusohjelman laajoja viivoja ja tehdä erilaisia ​​valintoja. Itse asiassa, jos pystyt siihen, kannustan sinua tekemään niin! 

        Viimeiseksi, panostaminen Ethereum 2.0: een on erittäin kokeellista ja edellyttää pitkäaikaista sitoutumista (jaan kolme vuotta). Älä osallistu, jos et ole tyytyväinen korkean tason hoitajaan, jos jotain on vielä kehitteillä. Jos et ole varma, pitäisikö sinun panostaa, liity ConsenSys-ristiriita ja kysy # teku-public -kanavalla. 

        Johdanto

        Edellisessä viestissä keskustelimme Ethereum 2.0: n käyttöönoton syistä ja kävelimme läpi 32 ETH: n Ethereum 1.0 mainnet -talletussopimuksessa. Koskimme avainten luomista ja panostamisprosessia Laukaisualusta linkittää Ethereum 1.0: n 2.0: een.

        Marraskuun 23. päivänä sidotun ETH: n vähimmäismäärä Ethereum 2.0: n käynnistämiseksi – noin 524 288 – saavutettiin. Ihmiset voivat edelleen olla mukana sopimuksessa, ja vahvistajien määrä on noussut yli 33 000: een 4. joulukuuta.

        MetaMaskin Aaron Davis kertoo ajatuksensa sisäisestä ConsenSys Slack -tapahtumakanavasta 

        Vaikka oli erittäin jännittävää päästä Genesis-lohkoon validoijana, sekuntia myöhemmin minulla oli samanlainen kokemus kuin kollegallani Aaron Davisilla sisäisellä ConsenSys-panoskanavallamme: Mihin hulluun tehtävään olin ilmoittautunut? Onneksi minulla on pääsy uskomattoman loistaviin ja teknisiin ihmisiin, jotka ovat riittävän hyväntekeväisyystarpeita antaakseen tälle ruubille vinkkejä, vihjeitä ja oivalluksia panostusinfrastruktuurin käytöstä. Toivon voivani välittää murto-osan tästä arvokkaasta neuvosta muille kiinnostuneille osapuolille.

        Näin tulee olemaan tämän artikkelin ensimmäinen osa: Mitkä ovat asioita, jotka sinun tulisi ottaa huomioon, kun valitset laitteita ja ohjelmistoja Ethereum 2.0 -validointiasiakkaan suorittamiseksi? Toinen osa käy läpi tietyn laitteisto / ohjelmisto-yhdistelmän, jonka olen valinnut validointiasiakkaalleni. Kokoonpanoon tekemäsi valinnat riippuvat resursseistasi, henkilökohtaisesta taipumuksestasi ja teknisestä kapasiteetistasi. Teen parhaani korostaakseni, kuinka henkilökohtaiset ennakkoluulot ja olosuhteet vaikuttivat valintoihini.

        Viimeiseksi, ennen kuin hyppäämme siihen, haluan toistaa, että nämä viestit ovat melkein kuin päiväkirjamerkinnät kokemuksestani 32 ETH: n (vaikkakin päiväkirjamerkinnöistä, joissa on kattavia teknisiä tietoja). Sellaisena voin muuttaa lähestymistapaani hieman majakkaketjun edetessä. Esimerkiksi ajattelin, että käytän ehdottomasti AWS: ää. Kuten luet alla, olen nyt harkinnut sitä uudelleen. Minulla on myös hyvin selvä panoksen taloudellinen osa. Panostaminen on tapa tukea Ethereumin ekosysteemiä, mutta kestävän julkisen käytön vuoksi sen tulisi olla myös ETH: n omaavien ihmisten saatavilla ja mahdollista. 

        Tulevaisuuden todentamislaitteet

        Vahvistimen käyttämisen nykyiset perusvaatimukset ovat suhteellisen helppo täyttää. Mara Schmiedt ja Collin Meyers Validator-opas on Banklessilla on vähäinen vähimmäisvaatimus. Ethereum 2.0 -validointilaitteiden määrittämisen haastavin osa on Beacon-ketjun vaiheen 0 nykyisten tarpeiden tasapainottaminen tulevaisuuden tuntemattomiin vaatimuksiin kehityksen jatkuessa. (Tämä ei ole huolenaihe, jos sinulla on mukava valvoa tarkasti validatoriasi ja pystyä käsittelemään muutokset nopeasti ja helposti.) 

        Ben Edgington, Teku – projektipäällikkö ja julkaisija Eth2.uutiset, toimitti minulle joitain reunatapauksia, joissa verkko saattaa vaatia enemmän validointiasiakasta. Lyhytaikainen, suurin huolenaihe olisi jotain Medalla-aikapalvelimen tapaus, jossa virhe ja myöhempi korjaus Prysm-asiakkaassa pysäytti testnetin viimeistelyn (karkeasti sanottuna verkko ei voinut “tuottaa lohkoja”). Koska verkossa ei ollut lopullisuutta (ei “vahvistettuja lohkoja”), validoijien oli pidettävä paljon enemmän tapahtumia RAM-muistissaan kuin normaalisti. 

        Koneet, joissa on 8 Gt RAM-muistia – mikä olisi ollut tarpeeksi normaalissa tilanteessa – alkoivat kohdata “muistin loppu” -ongelmia, jotka ovat saattaneet johtaa kaatumiseen. Tällainen piikki, vaikka epätavallinen, ei ole poissuljettua vaiheen 0 mainnetissä.

        Tulevaisuuden verkon kokoonpanon epäselvyydet ovat Ethereum 1.0: n ja 2.0: n yhdistäminen ja sirpaloitumisen käyttöönotto. Emme vieläkään tiedä, milloin nämä sulautumiset tapahtuvat tai mitä ne tarkalleen edellyttävät. Haluaisin, että vaiheeseen 0 siirtyisi vahva suorittimen runko (4 virtuaalista ydintä, 16 Gt RAM-muistia 100 Gt: n SSD: llä) ja sitten keskitän huomioni tuleviin säätöihin tallennustilan ympärillä (jättäen tilaa täällä). Huomaa, että tämä voi osoittautua ylenmääräiseksi ja syödä panospalkintoja.

        Nämä ovat tulevaisuuden “tunnettuja tuntemattomia”, keskustellaanpä validointilaitteiden tärkeimmistä kokoonpanopäätöksistä tänään.

        Suorita Eth1-asiakas tai suorita se?

        Se on kulkureitti, jonka yritän altistaa bootcamp-opiskelijoillemme mahdollisimman usein: synkronoimalla Ethereum 1.0 -asiakas. Se on avoin salaisuus, että “täyden” Ethereum 1.0 -solmun isännöinti on pikemminkin rakkauden teko kuin paadutettu vankilan dilemma-ratkaisu. “Täysi” täytyy laittaa lainausmerkkeihin, koska jopa Ethereumin ydinkehittäjillä on vaikeuksia sopia määritelmästä, mitä “täysi solmu” todella tarkoittaa.

        Yhdestä asiasta voimme olla yhtä mieltä: Ethereum 1.0 -asiakkaan synkronointi vie enemmän aikaa ja tallennustilaa kuin kuvitellakaan. Vahvistimillamme on oltava tapa kysyä Ethereum 1.0 -verkkotietokantaa (selvitämme syyn hieman myöhemmin). Jos haluat säästää paikallisen synkronoinnin tilaa ja päänsärkyä, voit käyttää Infura-päätepistettä, joka on saatavana ilmaiseksi rekisteröinnin yhteydessä. 

        Vaikka tämä säästää huomattavaa tallennustilaa ja logistista huolta, se uhraa tietyn määrän hajauttamista Eth1- ja Eth2-verkoille samanaikaisesti. Jos Infura menisi alas, mikä on äärimmäisen harvinaista mutta tapahtuu, se aiheuttaisi aaltoileva vaikutus Ethereum 2.0 -validisaattoreissa, jotka käyttävät sitä Ethereum 1.0 -päätepisteessään. Jotain harkittavaa!

        (Pelkästään selvyyden vuoksi: Ethereumin täyden solmun synkronoinnin vaikeus liittyy Ethereum-maailman valtion luonteeseen, ei Ethereum 1.0 -ydinkehittäjiin, jotka ovat tehneet hämmästyttävää työtä tämän erittäin haastavan ongelman ratkaisemisessa.)

        Virtuaalinen vs. paikallinen isännöinti

        Seuraava huomio minulle oli validointisolmun isännöinti paikallisesti (kotona) tai virtuaalisesti (virtuaalipalvelujen tarjoajalla, kuten Amazon Web Services (AWS), Digital Ocean jne.). Kuten mainitsin edellisessä kappaleessa, en luota itseäni ajaa yhtenäistä validointisolmua kotoa, jopa vanhalla kannettavalla tietokoneella, joka on tallennettu jonnekin. Kömpelö ja hölmö, potkaisin sen yli tai unohdin sen.

        Päätän suorittaa solmuni AWS: llä, koska se on minulle parhaiten perehtynyt (Koko tämän prosessin jälkeen arvaan kuitenkin toisen kerran tämän päätöksen. Keskustelen tästä myöhemmin). Kompromissi on jälleen hajauttaminen: Jos AWS laskee tai sillä on ongelmia (kuten äskettäin), Olen heidän armonsa. Jos riittävästi ihmisiä käyttää solmuja AWS: llä, se voi vaikuttaa suurempaan Ethereum-verkkoon.

        Ihmiset todennäköisesti valitsevat itse tämän. Paikallinen isännöinti on erityinen projekti, eikä kaikilla ole aikaa, resursseja tai sitoutumista. Vaikka virtuaalinen isännöinti on keskittämisvoima, päätän mennä siihen sen helppokäyttöisyyden ja (toivottavasti) taatun käyttöajan vuoksi. 

        Jos haluat suorittaa validointisolmun paikallisesti, voit silti noudattaa tämän opetusohjelman yleisiä ohjeita, Somer Esatin erinomainen opetusohjelma eri asiakkaiden kanssa tai jopa synkronoida Raspberry Pi Model 4B, jossa on 8 Gt RAM-muistia, Ethereumin kanssa ARM: lla. (Raspberry Pi: n synkronointi on edelleen erittäin kokeellista, ja ihmisten pitäisi odottaa, kunnes Ethereum ARM-tiimissä vahvistaa sen vakauden.)

        Eth2-asiakkaan valinta ja rangaistusten välttäminen

        Toinen merkittävä valinta on Ethereum 2.0 -asiakas nykyisten asiakkaiden joukossa: Majakka, Johtotähti, Nimbus, Prysm ja Teku. Olen erittäin puolueellinen Tekua kohtaan, enkä ole tarpeeksi taitava keskustelemaan asiakkaiden hienoista näkökohdista. Tämä artikkeli on kunnollinen yleiskatsaus Medallan asiakkaiden suorituskykyyn. (Muista, että Medalla vaati prosessoreilta paljon enemmän kuin mainnet.)

        Panoksen todistaminen sisältää nimenomaisia ​​estäviä tekijöitä kannustamaan oikeaa käyttäytymistä verkossa. Ne ovat muodoltaan dinging-vahvistimia offline-tilassa ja dramaattisempia liikkeellelähtöjä toimijoiden tahallisten toimien toteuttamiseksi verkkoa vastaan ​​tietoisesti tai muutoin.

        Yleisin ongelma on varmistaa, että vahvistimesi on verkon käytettävissä. Tämä tarkoittaa, että varmentaja on verkossa. DevOps-lähestymistapa tähän ongelmaan – luodaan valvonta- ja hälytysjärjestelmä varoittamaan sinua, jos vahvistimesi menee offline-tilaan – jota en käsittele täällä.

        Mutta on toinen tapa olla poissa verkosta, ja se on, jos asiakkaasi alkaa toimia väärin syystä tai toisesta. Jälkeen aikapalvelinvirhe aiheutti verkon hidastumisen Medallassa, Eth2-ytimen kehittäjät kokoontuivat kehittämään “[A] avaimen allekirjoitushistorian siirtämisen vakiomuoto antaa vahvistajien vaihtaa helposti asiakkaiden välillä ilman riskiä allekirjoittaa ristiriitaisia ​​viestejä.” Kaikilla asiakkailla ei ole tätä suojausta, mutta Tekulla on. Täältä voit lukea Tekun Slash Protectionin käytöstä (suoritetaan oletusarvoisesti), mukaan lukien siirtyminen Teku-solmujen tai muun kuin Teku-solmun välillä Teku-solmuun.

        Jos sinulla on ongelmia asiakkaasi kanssa ja sinun on käynnistettävä koko verkko uudelleen, sinun on oltava tietoinen heikosta subjektiivisuudesta. Työtodistuksen avulla kuka tahansa voi palata verkon geneesilohkoon ja rakentaa verkon tilaa luotettavasti tyhjästä. Panoksen todistuksella on kuitenkin tältä osin havainto: Jos kolmasosa verkon validoijista tietyssä pisteessä lopettaa edelleen lohkojen ja todistusten allekirjoittamisen, he voivat muuttaa verkon tilaa ja syöttää kyseiset väärät tiedot solmuun, joka synkronoi verkko, jos haitalliset toimijat tarttuvat synkronointisolmuun ennen kuin synkronointisolmu saavuttaa paikan, jossa validoijat nostivat varansa. Voit lukea lisää täältä, mutta lyhyt vastaus on, että sinulla on oltava joko “heikko subjektiivisuuden tarkistuspiste” tai koodattu tilatiedosto, lähinnä verkon arkisto. Teku tarjoaa startup-liput molemmille.

        Viimeinen rangaistushuolenaihe on vakavin: Slash. Vilkkuu tapahtuu, kun sidosryhmä toimii verkon sääntöjen vastaisesti. Se eroaa rangaistuksesta offline-tilassa olemisesta. Se toimii aktiivisesti verkkoa vastaan ​​lähettämällä ristiriitaisia ​​validointitietoja. Siellä on todella hienoja materiaaleja, joiden avulla voit oppia lisää leikkaamisesta ja sen estämisestä:

        Tärkein takeaway ei ole käyttää yhtä vahvistusavainta useilla asiakkailla. Ilmeisesti tämä aiheutti kaikkien aikojen ensimmäisen tapahtuman, joka tapahtui 2. joulukuuta. Siitä lähtien on tehty useita viiltoja! Jos siirryt yhdestä instanssista toiseen, tarkista nelinkertaisesti, että sinulla ei ole kahta konetta, jotka työskentelevät samasta avaimesta:

        Papa Ben kertoo sen sellaisenaan. Lähde

        AWS + Infura + Teku Validator -määritystiedot

        Oma Genesis-lohkon määritys:

        Käyttöjärjestelmä: Ubuntu Server 20.04 LTS (HVM) (Amazon-verkkopalvelu)

        Prosessori: Intel Xeon Platinum 8000 -sarjan prosessori, 3,1 GHz. (Amazon-verkkopalvelu)

        Muisti: 4 virtuaalista ydintä, 16 Gt RAM-muistia (Amazon Web Service)

        Varastointi: 100 Gt: n SSD, 300/3000 IOPS (Amazon Web Service)

        Ethereum 1.0 -asiakas: Infura-päätepiste (vapaa taso)

        Ethereum 2.0 -asiakas: Teku

        Tarkastellessani kaikkia yllä olevia näkökohtia en ollut varma parhaasta lähestymistavasta validointiasennuksen rakentamiseen. Itse haluaisin valita koneen, enkä yleensä huolehdi sen vaihdosta vähintään kahden vuoden ajan. Tämä auttaa vahvistimen kokonaiskustannuksissa (saan huomattavan alennuksen lukitsemalla virtuaalisen palveluntarjoajan muutaman vuoden ajan), enkä ole erityisen ketterä palvelimien pyörittämisessä. Tämä tulevaisuuden todistaminen tai “liian täsmennetty” lähestymistapa toivottavasti tekee elämästäni seuraavien kahden vuoden aikana hieman helpompaa.

        Aluksi olin varma, että AWS oli paras virtuaalialusta, ja sitä palvelua käytän tähän ja seuraavaan viestiin. Kuitenkin, kun olen käynyt läpi koko prosessin, tajusin, että AWS saattaa olla ylivoimainen yksittäiselle kehittäjälle. AWS: n todellinen vahvuus näyttää olevan sen kyky dynaamisesti laajentua vastaamaan kysyntään, josta aiheutuu ylimääräisiä kustannuksia. Tämä on taloudellisesti järkevää laajamittaiselle yritystason projektille, mutta yksittäiselle Ethereum 2.0: lle nykyinen Asiakkaan vaatimukset eivät vaadi tällaista tarkkuutta.

        Jatkan AWS: n kanssa, mutta viihdyn myös mahdollisuudesta suorittaa ilmentymä Digital Oceanilla, mikä saattaa olla sopivampi yksittäiselle kehittäjälle. Lisää siitä myöhemmin.

        Määritä Infura-tili

        Valitsen käyttää Infuraa Ethereum 1.0 -päätepisteeksi. Toistaiseksi majakkaketju seuraa Ethereum 1.0: n talletussopimusta aktivoidakseen uudet sidosryhmät, kun he ovat tallettaneet asianmukaisesti 32 ETH: n ja toimittaneet asianmukaiset BLS-allekirjoitukset.

        Tulevaisuudessa majakkaketju alkaa testata jatkokäsittelyä aloittamalla Ethereum 1.0: n tilatietojen käytön yhdensuuntaisten tarkistuspisteiden luomiseksi majakkaketjulle.

        Kuten edellä mainitsimme, näkyvyys Ethereum 1.0 -verkossa on kaksi päämenetelmää. Yksi on synkronoida ja ylläpitää aktiivisesti Ethereum 1.0 -solmu, joka luo paikallisen Ethereum 1.0 -tilatietokannan. Toinen on käyttää Infuran kaltaista palvelua, joka tarjoaa helpon Ethereum 1.0 -päätepisteen, johon pääsee HTTPS: n tai WebSockets.

        Kirjaudu sisään täällä. Kun sinulla on tili, napsauta Ethereum-logoa vasemmalla puolella.

        Napsauta “Luo uusi projekti” oikeassa yläkulmassa

        Nimeä projekti (minun on Eth 2 Validator) ja siirry kohtaan Asetukset. Varmista, että verkon päätepisteet ovat Mainnet ja kopioi HTTPS-päätepiste:

        Käytämme tätä myöhemmin Teku-asiakkaan käynnistyskomennossa!

        AWS-ilmentymän määrittäminen

        EC2-instanssin määrittäminen Amazoniin on suoraviivaista. Meillä on muutama muutos täällä ja siellä, jotta virtuaalinen esiintymämme voisi toimia hyvin Tekun kanssa.

        Luo AWS-tili (eri kuin Amazon.com-tili) ja kirjaudu sisään AWS-konsoliin. Siirry EC2-sivulle, joka näyttää tältä:

        Napsauta Käynnistä instanssi -painiketta. Sitten näet seuraavan ruudun:

        Käyttöjärjestelmä

        Täällä valitsemme, mitä konekuvaa (jota ajattelen käyttöjärjestelmänä) haluaisimme käyttää virtuaalisessa instanssissamme. Valitsen Ubuntu Server 20.04, joka on Linux-pohjainen palvelinympäristö. Ubuntu Server -ympäristössä on muutamia keskeisiä optimointieroja Ubuntu Desktop -ympäristöön nähden. Tärkein ero tarkoituksiimme on, että Ubuntu-palvelimelta puuttuu graafinen käyttöliittymä (GUI). Minne olemme menossa, siellä on vain komentorivi! Palauttaa minut takaisin Apple II -päiviin.

        Valittuamme käyttöjärjestelmän, valitsemme sitten ilmentymän tyypin:

        Minusta tämä valikko on melko ylivoimainen, joten aion jakaa sen hieman sinulle. Tässä valitaan koneemme laskentaydin / RAM-teho / suoritin. Se on koneen “raaka” tai “aktiivinen muisti” ja erillinen laitteen tallennustilasta (kiintolevy). Ajattele sitä virtuaalisen instanssimme moottorina, jolla käytämme Ubuntu Server -käyttöjärjestelmäämme. AWS erottaa nämä erillisiksi ilmentymäperheiksi, jotka on merkitty vasemman reunan sarakkeessa olevilla kirjain / numero-yhdistelmillä.

        Esimerkkiperheillä on erilaiset laitteistojärjestelyt samalla tavalla kuin eri automoottoreilla on erilaiset kokoonpanot männät, tulpat ja polttoaineet vastaamaan erilaisia ​​vaatimuksia. Keskitymme kahteen heidän “yleisen laskennan” ilmentymäperheensä, m5 ja t3.

        Valitsen m5.xlarge-ilmentymän, joka tarjoaa 4 virtuaalista laskentaydintä (vCPU) ja 16 Gt RAM-muistia. Käyttäessäni Ethereum 2.0 mainnet -ohjelmaa noin päivän, koneeni ei ole käyttänyt yli 4% käytettävissä olevasta vCPU: sta. Kuten yllä olevassa Tulevaisuuden todentaminen -osiossa mainittiin, Ethereum 2.0 -verkkovaatimukset vain kasvavat. Mutta seuraavien kuukausien aikana, ilman pitkittyneitä suuria verkon piikkejä, olisin todennäköisesti kunnossa m5.large-esiintymällä (2 virtuaalista ydintä / vCPU: ta, 8 Gt RAM-muistia)

        Tekniset ihmiset, jotka ovat älykkäämpiä kuin minä, ovat myös suosittaneet t3.large-esimerkkiä kohtuullisena vaihtoehtona Ethereum 2.0: lle. t3.large: lla on 2 vCPU: ta ja 8 Gt muistia, sama kuin m5.large, mutta t3-perhe on rakennettu “purskeisemmalle” verkkotoiminnalle (piikit prosessorissa) eikä m5-perheelle, joka on rakennettu tasaisille suorittimen kuormille.

        Hinnoittelu

        Viimeinen asia, joka on mainittava ennen kuin siirrymme varastointiin, on hinta. AWS on kallista verrattuna muihin vaihtoehtoihin, kuten Digital Ocean. Maksat suorittimesta (esim. Perheesi) ja tallennustilasta (kiintolevy) erikseen sen mukaan, mitä käytät. CPU maksetaan tunneittain. Koska vahvistajien on oltava online-tilassa 24 tuntia, voit käyttää alla olevaa hintataulukkoa (joulukuusta 2020 alkaen) tehdäksesi karkeita laskelmia: 

        Nämä ovat tilaustuotteita. AWS tarjoaa jotain kutsuttua Varattujen instanssien hinnoittelu, Jos lupaat käyttää virtuaalista esiintymää vuodesta kolmeen vuoteen, voit saada jopa 50-60% alennuksen yllä olevasta hintataulukosta. (Kiitos Jason Chromanille tästä vinkistä!)

        Napsauta EC2: n kotisivulla vasemmalla olevasta valikosta “Varatut instanssit”, joka näkyy alla:

        Napsauta “Osta varattu esiintymä”:

        Lisää avautuvaan valikkoon ilmentymän tyypin tiedot ja haluamasi aika nähdäksesi hinnoittelu (valitsen m5.xlarge ja 36 kuukauden termi):

        Napsauta “Hae” ja katso hintavaihtoehdot:

        Siellä on huomattava hintaalennus, uskon yli 50%, mutta olen lukittu kolmeen vuoteen. Kun olet ostanut varatun esiintymän, AWS käyttää sitä olemassa olevaan virtuaalilaatikkoon tai käyttää sitä, kun se on käynnistetty. Muista, että tämä EI sisällä tallennustilaa (kiintolevy). 

        Huomaa: En tee tätä vielä, koska en ole vielä vakuuttunut siitä, että AWS on paras vaihtoehto yksilölle, joka panostaa yhdestä kolmeen Ethereum 2.0 -validointisolmua. Käytän on-demand-hinnoittelua käyttävää instanssia, jotta voin nähdä, miten se menee ennen sitoutumista. 

        Varastointi

        Palataan instanssin käynnistysprosessiin ja siirrymme Lisää tallennustila -välilehdelle

        Laajat tekniset asiantuntijat, joille kysyin, suosittelivat 100 Gt: n yleiskäyttöisen SSD: n tallennustilaa. Tallennus ei tyypillisesti ole pullonkaula Eth2-asiakkaiden kanssa. Tämä on kuitenkin ilman käynnissä täysi Eth1-asiakas. Eth1-tallennustilaa varten konservatiivinen arvio olisi noin 1 Tt. Muista ottaa tämä huomioon, jos et käytä Infuraa.

        En tiedä yllä olevan kuvan IOPS-sarakkeessa olevaa yksikköä, mutta se on prosessorin kanssa kommunikoivan kiintolevyn tulo-lähtö. Tämä on klassinen pullonkaula Eth1-solmujen täydelliseen synkronointiin. Jos haluat synkronoida täyden Eth1-asiakkaan tällä koneella ja sinulla on ongelmia, tämä voi olla paikka etsiä.

        Portit

        Ohita Lisää tunnisteet -vaihtoehto ja siirry kohtaan Määritä suojausryhmä. Nämä ovat erilaisia ​​aukkoja, jotka on luotu erilaiselle saapuvalle ja lähtevälle viestinnälle ilmentymän kanssa.

        AWS avaa automaattisesti perinteisen SSH-portin, koska se on pääasiallinen tapa olla vuorovaikutuksessa ilmentymän kanssa. Kolikko Cashew ja Somer Esat Erinomaiset oppaat suosittelevat salasanan käytön poistamista käytöstä SSH: lle, mutta näemme, kun käynnistämme ilmentymän, joka ei ole AWS: n oletusasetus. On kuitenkin hyvä satunnaistaa SSH-porttisi numeroon välillä 1024-65535. Tämä estää haitallisia toimijoita skannaamasta vakiona SSH-porttia verkossa. Katso, kuinka SSH-portti suojataan yleensä tässä ja erityisesti AWS: lle tässä.

        Meidän on lisättävä kaksi turvasääntöä Teku-asiakkaan mukauttamiseksi, ja se liittyy vertaisviestintään. Lohkoketjuverkot ovat hajautettuja siinä mielessä, että solmut puhuvat suoraan keskenään. Keskitetyn solmun kuulemisen sijaan yksittäinen solmu kehittää ja ylläpitää ymmärrystä verkon tilasta “juoruilemalla” monilla solmuilla. Tämä tarkoittaa sitä, että kun yksi asiakas kättelee toisen kanssa, he vaihtavat tietoja verkosta. Tehty tarpeeksi kertaa eri solmuilla, tieto leviää koko verkossa. Tällä hetkellä Eth2 Validator -solmullani on 74 ikätoveria, joiden kanssa se juttelee.

        Teku on yhteydessä muihin 9000-portin solmuihin, joten avaamme sen UDP: lle ja TCP: lle, kaksi erilaista tiedonsiirtoprotokollaa. 

        Jälkeenpäin sen pitäisi näyttää tältä:

        SSH-avaimet ja ilmentymien käynnistys

        Siirry viimeiseksi kohtaan “Tarkista ja käynnistä”, yleiskatsaus tehdyistä valinnoista. Hyväksynnän jälkeen avautuu ponnahdusvalikko SSH-avaimista. En näytä omaani, koska se sisältää arkaluontoisia tietoja. Nimittäin avainparia käytetään todentamaan ja kirjautumaan virtuaaliseen ilmentymään SSH: n (paikallinen komentorivi) kautta. Jos sinulla ei vielä ole paria, AWS luo sellaisen sinulle. Sinun on ladattava tämä ja kohdeltava sitä kuin Ethereumin yksityinen avain! Se on ainoa tapa muodostaa yhteys ilmentymään, eikä AWS tallenna sitä sinulle.

        Kun kaikki on hunky-dory, tämä ikkuna tulee näkyviin:

        Okei! Siitä on tehty. Siirrytään tapaamisemme käyttämiseen ja suojaamiseen ja asennetaan sitten Teku!

        Käytetään instanssia

        Tärkein tapa käyttää AWS-ilmentymää on SSH: n kautta, “Salausprotokolla verkkopalvelujen turvalliseen käyttämiseen suojaamattomassa verkossa.” Kuten aiemmin mainittiin, AWS poistaa oletusarvoisesti salasanan todennuksen käytöstä ilmentymää käytettäessä. Voit käyttää vain ennen ilmentymän käynnistämistä luotua avainparia. Avainparin pitäisi olla a.pem-tiedoston loppu. 

        AWS tarjoaa puhtaan tavan saada SSH-komentosi. Napsauttamalla käynnissä olevaa instanssia EC2-pääsivulta, oikeassa yläkulmassa on painike, joka sanoo “muodosta yhteys”:

        Seuraavalla sivulla on SSH-komento, joka on omalle ilmentymällesi. Se rakentuu seuraavasti:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [sähköposti suojattu]_IDENTIFIER.compute-ZONE.amazonaws.com

        Tämän komennon syöttäminen päätelaitteeseen aloittaa SSH-istunnon. Ensimmäistä kertaa paikallinen kone kysyy, haluatko luottaa AWS: n toimittamaan ECDSA: n sormenjälkeen. Tämä estää a mies-keskellä-hyökkäys ja tarvittaessa käyttäjä voi saada ilmentymänsä sormenjäljen nämä vaiheet.

        Siirrä vahvistusavaintiedostot, jotka tarvitaan Tekun suorittamiseen, nykyisestä SSH-istunnosta erillisessä päätelaitteessa. Edellisessä blogikirjoituksessa kävelimme läpi 32 ETH: n ja saimme validointiavaimet Ethereum 2.0: lle. Lopulta meille jäi tämä tiedostorakenne:

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

        Meidän on siirrettävä validator_key_info-tiedosto virtuaalisiin esiintymiimme. Secure Copy Protocol (scp) antaa meille mahdollisuuden tehdä tämä turvallisesti. Mukauta alla oleva yleinen scp-komento käyttämällä yllä olevan hakemiston polkua ja edellistä SSH-komentoa:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [sähköposti suojattu]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Huomaa ”: ~” koko komennon loppuun.)

        Tiedostonsiirron pitäisi tapahtua. Jos navigoit takaisin SSH-istuntoosi ja kirjoitat ls, sinun pitäisi nähdä siirretty hakemisto.

        Tekun asentaminen

        Nyt kun meillä on tarvitsemamme validointitiedostot, aiomme asentaa Tekun. Ensinnäkin meidän on päivitettävä olemassa olevat ohjelmat ja asennettava tarvittavat Java-järjestelmät:

        Asenna Java

        sudo apt -päivitys && sudo apt install default-jre && sudo apt install default-jdk

        Tarkista, että Java-asennus on onnistunut seuraavilla tavoilla:

        java -versio

        Asenna Binary

        Löydä uusin vakaa Teku-julkaisu täältä. Kopioi linkin osoite tar.gz-tiedostoon ja lataa se sitten SSH-istunnostasi. Tältä minun näytti, versiosi on todennäköisesti erilainen:

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

        Pura ladattu tiedosto seuraavalla komennolla. Jos sinulla on eri versio, sub-tiedoston nimi toisin kuin teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Poista puhtauden vuoksi tar.gz-tiedosto.

        Kaikkien näiden vaiheiden jälkeen kotihakemistosi tulisi näyttää tältä (Tekun versionumero ja sisältö voivat olla erilaiset:

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

        Luo ei-root-käyttäjä

        Tämä vaihe kopioidaan Somer Esat -sivustolta erinomainen Ubuntu / Teku-opetusohjelma

        Aiomme luoda ei-root-käyttäjän nimeltä teku, joka voi käyttää Tekua. Kirjoita seuraava:

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

        Aiomme luoda mukautetun tietohakemiston myös Tekulle ja antaa sitten teku-käyttäjälle pääsyn siihen:

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

        Luo systemd-palvelu

        Tämä vaihe on mukautettu Somer Esat -lehdestä erinomainen Ubuntu / Teku-opetusohjelma

        Tämä vaihe tekee palvelun, joka suorittaa Tekun taustalla. Se antaa myös koneen käynnistää palvelun automaattisesti uudelleen, jos se pysähtyy jostain syystä. Tämä on välttämätön askel varmistaaksemme, että vahvistajamme toimii 24–7.

        Luo palvelutiedosto nano-tekstieditorilla:

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

        Tässä tiedostossa (jonka pitäisi olla tyhjä), aiomme laittaa sarjan komentoja, jotka systemd suorittaa, kun aloitamme palvelun. Tässä on alla oleva koodi, sinun on annettava seuraavat kohteet, jotka olemme keränneet tämän matkan aikana:

        • Infura Eth1 HTTP-päätepiste
        • validator_key_info-hakemistopolku kahdella kelvollisella avaimiin liittyvällä tiedostolla
        • Mukautettu tietopolku (lib / var / teku)

        Lisää nämä arvot alla olevaan lihavoituun koodiin ja kopioi sitten kaikki nano-tekstieditoriin:

        [Yksikkö] Kuvaus = Teku-majakkasolmu haluaa = verkko-online.target jälkeen = verkko-liikenne.target [palvelu] tyyppi = yksinkertainen käyttäjä = teku ryhmä = teku uudelleenkäynnistys = aina uudelleenkäynnistys = 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/KEYST45_Kysäys/KEYST/ –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –tietokanta-polku = / var / lib / teku [Asenna] WantedBy = multi-user.target

        Kirjoita komento-X ja kirjoita sitten “Y” tallentaaksesi muutokset

        Meidän on käynnistettävä “systemctl” uudelleen sen päivittämiseksi:

        sudo systemctl daemon-reload

        Käynnistä palvelu:

        sudo systemctl Käynnistä teku

        Tarkista, että se alkaa kunnolla:

        sudo systemctl tila teku

        Jos näet virheitä, saat lisätietoja suorittamalla:

        sudo journalctl -f -u teku.palvelu

        Voit pysäyttää Teku-palvelun suorittamalla:

        sudo systemctl lopettaa teku

        Tarkista Tekun vianmäärityssivulta yleisiä virheitä tai katso Teku-ristiriita, jota joukkue valvoo.

        Kun sinusta tuntuu, että asiat on ratkaistu, salli palvelu käynnistymään uudelleen, jos se sammuu suorittamalla:

        sudo systemctl ota käyttöön teku

        Sinulla on se! Asioiden pitäisi kypsyä pitkin juuri nyt. Tarkastellessasi Teku-palvelua näet lokisarjan, joka merkitsee synkronointitapahtuman. Tämä on vahvistimesi, joka synkronoi majakkaketjun. Kun se saavuttaa pään, nämä lokit muuttuvat lukemaan kolikkotapahtuman, ja näet myös todistustesi ja estoehdotukset.

        Tuoda markkinoille

        Lähde: Beaconcha.in

        1. joulukuuta kello 12 UTC, Beacon-ketjun ensimmäiset lohkot vahvistettiin. Ensimmäinen lohko tuli Validator 19026, arvoituksellisen graffitin kanssa, “herra F oli täällä.” Kaksitoista sekuntia myöhemmin tuli seuraava lohko, graffitit osoittavat, että validointilaite saattaa sijaita Zug, Sveitsi. Eth2 Beacon -ketju kasvoi tasaisesti, lohko kerrallaan 12 sekunnin välein. Sitten tuli seuraava este: olisiko riittävästi validoijia verkossa ensimmäisen aikakauden viimeistelemiseksi? Joo! 82,27% validoijista todisti majakkaketjun Epoch 0: n, sananlaskevan pohjakerroksen, pätevyyden. Voit lukea lisää Beacon-ketjun lanseerauksesta ja seuraavasta täältä. 

        Lähde: Beaconcha.in

        Olemme nyt Epoch 760 -mallissa, mikä tarkoittaa, että Beacon-ketju on toiminut sujuvasti melkein viikon. 

        Tässä on kuva näkökulmastani syntymishetkestä tässä viestissä kuvatulla asetuksella:

        Seuraavassa erässä tehdään yhteenveto siitä, miten asiat menevät. Aion käyttää Tekun mittareita, keskustella AWS: n käyttökustannuksista ja keskustella lyhyesti verkon tilasta.

        Pysy kanavalla!

        Resurssit ja linkit

        Kiitos James Beckille, Meredith Baxterille, Jason Chromanille, Aaron Davisille, Chaminda Divitotawelalle, Ben Edgingtonille, The Dark Jesterille, Somer Esatille, Joseph Lubinille, Collin Meyersille, Nick Nelsonille, Mara Schmiedtille, Adrian Suttonille ja Alex Tudoracheelle tuesta ja teknisestä avusta.

        Ethereum 2.0UutiskirjeTilaa uutiskirjeemme, jossa on uusimmat Ethereum-uutiset, yritysratkaisut, kehittäjien resurssit ja paljon muuta.

        Mike Owergreen Administrator
        Sorry! The Author has not filled his profile.
        follow me