NewsDevelopersEnterpriseBlockchain ObjašnjeniDogađaji i konferencijePressBilteni

Pretplatite se na naše obavijesti.

Email adresa

Poštujemo vašu privatnost

HomeBlogDevelopers

Moje putovanje kako bih postao validator na Ethereumu 2.0, 2. dio

Koje su stvari koje biste trebali uzeti u obzir prilikom odabira hardvera i softvera za pokretanje klijenta za provjeru valjanosti Ethereum 2.0? Napisao Coogan Brennan, 5. prosinca 2020. Objavljeno 5. prosinca 2020.

Napomena: I dalje možete postati validator na mreži Ethereum 2.0! Postojat će vrijeme čekanja koje će se aktivirati kao validator – od 4. prosinca 2020. vrijeme čekanja je približno 9,9 dana. Pogledajte korake za postavljanje uloga u 1. dijelu ove serije.

1. Odricanje
2. Uvod
3. Razmatranja o konfiguraciji validatora

1. Hardver za provjeru budućnosti
2. Pokrenuti ili ne pokrenuti Eth1 klijenta?
3. Virtualni vs lokalni hosting
4. Izbor klijenta Eth2 i izbjegavanje kazna

Postavljanje instance AWS

Operacijski sustav

Cijene

Skladištenje

Luke

Pokretanje SSH ključeva i instanci

Instaliranje Tekua

Zahtjevi

Instalirajte binarni

Stvorite korisnika koji nije root

Izradite systemd uslugu

Pokrenite

Odricanje

Ovo je post koji pišem kao zaposlenik ConsenSys-a i netko tko planira ulagati u lanac svjetionika. Prva izjava znači da dajem prednost proizvodima ConsenSys (proizvodi ConsenSys obično su najbolji u klasi za Ethereum, a također imam pristup inženjerskim timovima koji mi mogu pomoći odgovoriti na pitanja i riješiti probleme). Potonja izjava znači da optimiziram troškove i jednostavnost upotrebe: nemam tisuće ETH-a da bih donio značajne nagrade, pa koristim neke prečace. Ovo su odluke koje sam donio kako bih ulaganje u Ethereum 2.0 učinio što jednostavnijim i dostupnijim pojedincima, ali uz kompromise u vezi s decentralizacijom i privatnošću. Međutim, možete pratiti široke poteze donjeg vodiča i donijeti različite izbore. Zapravo, ako to možete učiniti, poticao bih vas! 

Na kraju, ulaganje u Ethereum 2.0 vrlo je eksperimentalno i uključuje dugoročno opredjeljenje (dodjeljujem tri godine). Molimo vas da ne sudjelujete ako vam nije ugodno lice s visokom razinom rizičnog pratioca s nečim što je još u fazi izrade. Ako niste sigurni biste li trebali uložiti, pridružite se ConsenSys nesklad i pitajte u kanalu # teku-public. 

Uvod

U prethodnom postu raspravljali smo o razlozima postavljanja Ethereum 2.0 i prošetali kroz ulog od 32 ETH u Ugovoru o depozitu matične mreže Ethereum 1.0. Dotaknuli smo se generiranja ključeva i načina na koji se vrši ulog Launchpad povezuje Ethereum 1.0 do 2.0.

23. studenog zadovoljen je minimalni iznos uloženih ETH za pokretanje Ethereuma 2.0 – oko 524.288. Ljudi mogu i dalje sudjelovati u ugovoru, a broj validatora popeo se na preko 33 000 od 4. prosinca.

Aaron Davis iz MetaMaska dijeli svoja razmišljanja u internom kanalu za ulaganje ConsenSys Slack 

Iako je bilo izuzetno uzbudljivo ući u Genesisov blok kao validator, sekunde kasnije doživio sam slično iskustvo s kolegom Aaronom Davisom u našem internom kanalu ConsenSys-a: Za koji sam se ludi zadatak prijavio? Srećom, imam pristup nevjerojatno briljantnim i tehničkim dovoljno dobrotvornim ljudima koji ovoj rubi mogu dati neke savjete, upute i uvid u upravljanje infrastrukturom ulaganja. Nadam se da ću djelić tog dragocjenog savjeta ovdje prenijeti bilo kojoj drugoj zainteresiranoj strani.

To će biti prvi dio ovog članka: Koje biste stvari trebali uzeti u obzir prilikom odabira hardvera i softvera za pokretanje Ethereum 2.0 klijenta za provjeru valjanosti? Drugi dio će proći kroz specifičnu kombinaciju hardvera i softvera koju sam odabrao za svog klijenta za provjeru valjanosti. Odabir za vašu konfiguraciju ovisit će o vašim resursima, osobnoj sklonosti i tehničkim mogućnostima. Dat ću sve od sebe da naglasim kako su osobne pristranosti i okolnosti informirale moj izbor.

I na kraju, prije nego što uskočimo u to, želim ponoviti da su ovi postovi gotovo poput članaka u časopisu zbog mog iskustva s 32 ETH (iako unosi u časopise s opsežnim tehničkim pomoćima). Kao takav, mogu malo promijeniti svoj pristup kako lanac svjetionika bude napredovao. Na primjer, mislio sam da bih definitivno koristio AWS. Kao što ćete pročitati u nastavku, sada to ponovno razmatram. Također ću biti vrlo jasan u vezi s financijskim elementom ulaganja. Ulog je način podrške ekosustava Ethereum, ali za održivu javnu upotrebu trebao bi biti dostupan i moguć ljudima koji imaju ETH da to učine. 

Hardver za provjeru budućnosti

Osnovne zahtjeve za pokretanje validatora danas relativno je lako zadovoljiti. Mara Schmiedt i Collin Meyers ‘ Vodič za provjeru valjanosti na Bankless-u ima dobar pregled minimalnih zahtjeva. Najizazovniji aspekt određivanja Ethereum 2.0 opreme za provjeru valjanosti je uravnoteženje trenutnih potreba faze Beacon Chain 0 s budućim trenutno nepoznatim zahtjevima kako se razvoj nastavlja. (To ne zabrinjava ako vam je ugodno pažljivo pratiti vaš validator i ako možete brzo i jednostavno adresirati promjene) 

Ben Edgington, voditelj projekta Teku i izdavač Eth2.news, pružio mi je neke rubne slučajeve u kojima bi mreža mogla zahtijevati više od klijenta za provjeru valjanosti. Kratkoročno, najveća briga bila bi nešto slično incident s vremenskim poslužiteljem Medalla, u kojem je bug i naknadni popravak u klijentu Prysm zaustavili finalizaciju na testnoj mreži (grubo govoreći, mreža nije mogla “proizvoditi blokove”). Budući da na mreži nije bilo konačnosti (nije bilo „potvrđenih blokova“), validatori su morali držati mnogo više transakcija u svojoj RAM memoriji nego što je uobičajeno. 

Strojevi s 8 GB RAM-a – što bi u normalnim okolnostima bilo više nego dovoljno – počeli su se susretati s problemima “bez memorije” što je moglo dovesti do rezanja. Ovakav skok, iako neobičan, nije na odmet za mrežnu mrežu Phase 0.

Buduće nejasnoće konfiguracije za mrežu su spajanje Ethereum 1.0 i 2.0 i uvođenje oštrine. Još uvijek ne znamo kada će se ta spajanja dogoditi ili točno što će biti potrebno. Želio bih imati snažnu okosnicu procesora koja ulazi u fazu 0 (4 virtualne jezgre, 16 GB RAM-a sa 100 GB SSD-a), a zatim usmjeriti pažnju na buduće prilagodbe oko prostora za pohranu (ovdje ostaviti prostor za miješanje). Imajte na umu da se ovo može pretjerati i pojesti nagrade.

To su “poznate nepoznanice” budućnosti, razgovarajmo o glavnim točkama odluke o konfiguraciji za validatore danas.

Pokrenuti ili ne pokrenuti klijenta Eth1?

To je obred pokušaja što češće podvrgavati naše studente iz bootcampa: sinkroniziranje klijenta Ethereum 1.0. Javna je tajna da je zapravo hosting “punog” čvora Ethereum 1.0 čin ljubavi, a ne otvrdnuto rješenje Prisoner’s Dilemma. “Puno” se mora staviti u navodnike jer se čak i programeri jezgre Ethereuma teško dogovaraju oko definicije što “puni čvor” zapravo znači.

Oko svega se možemo složiti: Potrebno je više vremena i prostora za sinkronizaciju klijenta Ethereum 1.0 nego što biste zamislili. Naši validatori moraju imati način ispitivanja mrežne baze podataka Ethereum 1.0 (zašto ćemo to saznati malo kasnije). Ako želite lokalno uštedjeti prostor i glavobolju sinkronizacije, možete upotrijebiti krajnju točku Infura, koji je uz registraciju dostupan besplatno. 

Iako ovo štedi značajnu pohranu i logističku zabrinutost, istovremeno žrtvuje određenu količinu decentralizacije za mreže Eth1 i Eth2. Kad bi Infura sišla, što je izuzetno rijetko, ali se događa, to bi izazvalo efekt mreškanja na validacijskim programima Ethereum 2.0 koji ga koriste za krajnju točku Ethereum 1.0. Nešto za razmotriti!

(Samo da budemo jasni: poteškoće sinkronizacije Ethereum punog čvora povezane su s prirodom svjetske države Ethereum, a ne s jezgrenim programerima Ethereum 1.0 koji su učinili nevjerojatan posao noseći se s ovim izuzetno izazovnim problemom.)

Virtualni vs lokalni hosting

Sljedeće razmišljanje za mene bilo je hosting čvora za provjeru valjanosti lokalno (u mojoj kući) ili virtualno (na virtualnom davatelju usluga kao što su Amazon Web Services (AWS), Digital Ocean, itd.). Kao što sam spomenuo u prethodnom članku, ne vjerujem si da ću pokrenuti dosljedni čvor validatora od kuće, čak i na starom prijenosnom računalu negdje pohranjenom. Nespretni i glupi, ili bih je prebacio ili zaboravio.

Odlučujem se pokrenuti svoj čvor na AWS-u, jer je to ono što mi je najpoznatije (međutim, nakon što sam prošao cijeli ovaj postupak, pretpostavljam ovu odluku. O tome ću raspraviti kasnije). Ovdje je kompromis opet decentralizacija: ako AWS padne ili ima bilo kakvih problema (kao nedavno), U njihovoj sam milosti. Ako dovoljan broj ljudi koristi čvorove na AWS-u, to može utjecati na veću mrežu Ethereum.

Ljudi će vjerojatno sami odabrati ovaj. Lokalni hosting posebna je vrsta projekta i nemaju svi potrebno vrijeme, resurse ili zalaganje. Iako je virtualni hosting centralizirajuća snaga, odlučujem se za njim zbog njegove jednostavnosti upotrebe i (nadam se) zajamčenog trajanja rada. 

Ako želite lokalno pokrenuti čvor validatora, još uvijek možete slijediti općenite upute ovog vodiča, Izvrsna serija tutorijala Somer Esat s različitim klijentima ili čak i sinkronizirajte Raspberry Pi Model 4B s 8 GB RAM-a s Ethereumom na ARM-u. (Sinkronizacija na Raspberry Pi još je uvijek eksperimentalna i ljudi bi trebali pričekati dok Ethereum na ARM timu ne potvrdi svoju stabilnost)

Izbor klijenta Eth2 i izbjegavanje kazna

Drugi glavni izbor je klijent Ethereum 2.0 među postojećim klijentima: Svjetionik, Zvijezda vodilja, Nimbus, Prizm i Teku. Jako sam pristran prema Tekuu i nisam dovoljno pametan da raspravljam o finim točkama klijenata. ovaj članak pristojan je pregled uspješnosti klijenta na Medalli. (Imajte na umu da je Medalla od procesora zahtijevala puno više nego što će to činiti mainnet.)

Proof of Stake uključuje eksplicitne destimulativne mjere za poticanje ispravnog ponašanja na mreži. Oni imaju oblik dinging validatora zbog toga što su izvan mreže i dramatičniji potez rezanja glumaca zbog poduzimanja zlonamjernih radnji protiv mreže, svjesno ili na drugi način.

Najčešći problem bit će osiguravanje da vaš validator bude dostupan mreži. To znači da provjerite je li vaš validator na mreži. Postoji DevOps-ov pristup ovom pitanju – stvaranje sustava za praćenje i upozoravanje koji će vas upozoriti ako vaš validator ode van mreže – koji ovdje neću pokriti.

Ali postoji još jedan način da mreža bude nedostupna, a to je ako vaš klijent počne loše postupiti iz jednog ili drugog razloga. Nakon greška poslužitelja vremena izazvao usporavanje mreže na Medalli, programeri jezgre Eth2 okupili su se radi razvoja “[A] standardni format za prijenos povijesti potpisivanja ključa omogućuje validatorima da se lako prebacuju između klijenata bez rizika od potpisivanja sukobljenih poruka.” Nemaju svi klijenti ovu zaštitu, ali Teku je ima. Ovdje možete pročitati o korištenju Tekuove zaštite od kosog crtica (izvodi se prema zadanim postavkama), uključujući migraciju između Teku čvorova ili ne-Teku čvora na Teku.

Ako imate problema sa svojim klijentom i trebate ponovno pokrenuti cijelu mrežu, morate biti svjesni slabe subjektivnosti. Proof of Work omogućuje svima da se vrate u genetski blok mreže i bez povjerenja grade stanje mreže od nule. Dokaz uloga, međutim, u tome ima zamku: Ako trećina validatora mreže na određenoj točki izlaska ipak nastavi potpisivati ​​blokove i potvrdu, oni mogu izmijeniti stanje mreže i napajati te lažne podatke čvoru koji se sinkronizira s mreža ako zlonamjerni akteri uhvate čvor za sinkronizaciju prije nego što čvor za sinkronizaciju dospije tamo gdje su validacijski sustavi povukli svoja sredstva. O tome možete pročitati više ovdje, ali kratki je odgovor da trebate imati ili „slabu kontrolnu točku subjektivnosti“ ili kodiranu datoteku stanja, u biti arhivu mreže. Teku pruža zastavice za pokretanje za oboje.

Posljednja zabrinjavajuća kazna najozbiljnija je: Slashing. Do rezanja kose dolazi kada zalagač djeluje protiv pravila mreže. Razlikuje se od kažnjavanja od izvanmrežnog. Aktivno djeluje protiv mreže dostavljanjem proturječnih podataka o validatoru. Postoji nekoliko zaista sjajnih materijala za učenje više o rezanju i kako to spriječiti:

• Prysmova sveobuhvatna, klijentsko-agnostička prevencija rezanja kose.

• r / Ethstaker Moderator Superphiz’s Rules of Thumb for Slashing

• Superphiz Razgovor s Jimom McDonaldom iz Attestanta o Slashingu

Glavno sredstvo za poneti je ne pokretati jedan ključ validatora na više klijenata. Očito je to ono što je uzrokovalo prvi rušivi događaj ikad, koja se dogodila 2. prosinca. Od tada je došlo do brojnih kosa! Ako migrirate s jedne instance na drugu, četverostruko provjerite da nećete imati dva stroja koji rade s istim ključem:

Papa Ben to govori kao da jest. Izvor

Specifikacije konfiguracije AWS + Infura + Teku Validator

Postavljanje bloka moje geneze:

Operacijski sustav: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

Procesor: Procesor Intel Xeon Platinum 8000 serije, 3,1 GHz. (Amazon web usluga)

Memorija: 4 virtualne jezgre, 16 GB RAM-a (Amazon Web Service)

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

Klijent Ethereum 1.0: Krajnja točka Infura (besplatna razina)

Klijent Ethereum 2.0: Teku

Gledajući sva gore navedena razmatranja, nisam bio siguran u najbolji pristup izgradnji postavki validatora. Za sebe bih želio odabrati stroj i općenito se ne brinem o promjeni barem dvije godine. To pomaže u ukupnim troškovima validatora (mogu ostvariti značajan popust ako se nekoliko godina prijavim kod virtualnog davatelja usluga) i nisam posebno spretan s okretanjem poslužitelja. Nadam se da će mi ovaj pristup provjere budućnosti ili „pretjeranog odabira“ olakšati život u sljedeće dvije godine.

U početku sam bio uvjeren da je AWS najbolja virtualna platforma i to je usluga koju ću koristiti za ovaj i sljedeći post. Međutim, nakon što sam prošao cijeli postupak, shvatio sam da bi AWS mogao biti pretjeran za pojedinog programera. Čini se da je stvarna snaga AWS-a njegova sposobnost dinamičkog povećanja kako bi se udovoljilo potražnji koja ima visoku cijenu. To ima ekonomskog smisla za veliki projekt na razini poduzeća, ali za pojedinačni Ethereum 2.0 Trenutno zahtjevi klijenta ne zahtijevaju takvu strogost.

Nastavit ću s AWS-om, ali također zabavljam mogućnost pokretanja primjerka na Digital Oceanu, što bi moglo biti prikladnije za pojedinog programera. O tome više kasnije.

Postavljanje računa Infura

Odlučio sam koristiti Infuru kao krajnju točku Ethereuma 1.0. Za sada, beacon lanac prati Ugovor o depozitu na Ethereum 1.0 kako bi aktivirao nove ulagače kada su pravilno položili 32 ETH i predali odgovarajuće BLS potpise.

U budućnosti će beacon lanac započeti testiranje daljnje obrade tako što će početi koristiti podatke o stanju iz Ethereuma 1.0 za stvaranje paralelnih kontrolnih točaka na beacon lancu.

Kao što smo gore spomenuli, postoje dva glavna načina za vidljivost mreže Ethereum 1.0. Jedna je sinkronizacija i aktivno održavanje čvora Ethereum 1.0, koji stvara lokalnu bazu podataka Ethereum 1.0. Druga je upotreba usluge poput Infure koja pruža jednostavnu krajnju točku Ethereum 1.0, dostupnu putem HTTPS-a ili WebSockets.

Prijavite se za račun ovdje. Nakon što imate račun, kliknite logotip Ethereuma s lijeve strane.

Kliknite “Stvori novi projekt” u gornjem desnom kutu

Nazovite svoj projekt (moj je “Eth 2 Validator”) i idite na “Postavke”, provjerite jesu li vaše mrežne krajnje točke “Mainnet” i kopirajte HTTPS krajnju točku:

To ćemo kasnije koristiti za naredbu za pokretanje Teku klijenta!

Postavljanje instance AWS

Postavljanje instance EC2 na Amazonu je jednostavno. Imat ćemo tu i tamo nekoliko dorade kako bismo pomogli našoj virtualnoj instanci da se dobro igra s Tekuom.

Izradite AWS račun (različit od računa Amazon.com) i prijavite se na AWS Console. Otvorite EC2 stranicu koja će izgledati otprilike ovako:

Kliknite gumb “Pokreni instancu”. Tada ćete vidjeti sljedeći zaslon:

Operacijski sustav

Tu odabiremo koju bismo sliku stroja (koju smatram operativnim sustavom) željeli koristiti na našoj virtualnoj instanci. Odabirem Ubuntu Server 20.04, koji je Linux okruženje poslužitelja. Okruženje Ubuntu poslužitelja ima nekoliko ključnih razlika u optimizaciji od okruženja Ubuntu Desktop. Glavna razlika u naše svrhe je što Ubuntu poslužitelj nema grafičko korisničko sučelje (GUI). Kamo idemo, postoji samo naredbeni redak! Vraća me u moje Apple II dane.

Nakon odabira našeg operativnog sustava, odabiremo vrstu instance:

Smatram da je ovaj izbornik prilično neodoljiv, pa ću ga malo razbiti za vas. Ovdje odabiremo računalnu jezgru / snagu RAM-a / CPU za naš stroj. To je “neobrađena” ili “aktivna memorija” uređaja i odvojena je od pohrane (tvrdog diska) uređaja. Shvatite to kao pokretač naše virtualne instance, na kojoj ćemo pokretati naš operativni sustav Ubuntu Server. AWS ih razdvaja u zasebne obitelji instance označene kombinacijom slova / broja u krajnjem lijevom stupcu.

Obitelji instanci imaju različite hardverske aranžmane baš kao što različiti automobilski motori imaju različite konfiguracije klipova, čepova i goriva kako bi udovoljili različitim zahtjevima. Usredotočit ćemo se na dvije njihove obitelji instance “općeg računanja”, m5 i t3.

Odabirem instancu m5.xlarge koja pruža 4 virtualne računalne jezgre (vCPU) i 16 GB RAM-a. Nakon pokretanja Ethereum 2.0 matične mreže otprilike jedan dan, moj stroj nije upotrijebio više od 4% dostupnog vCPU-a. Kao što je spomenuto u gornjem odjeljku „Ispitivanje budućnosti“, zahtjevi mreže Ethereum 2.0 samo će rasti. No, sljedećih nekoliko mjeseci, bez ikakvih produljenih velikih skokova na mreži, najvjerojatnije bih bio u redu s m5.large instancom (2 virtualne jezgre / vCPU, 8 GB RAM-a)

Tehničari pametniji od mene također su preporučili t3.large instancu kao razumnu opciju za Ethereum 2.0. t3.large ima 2 vCPU-a i 8 GB memorije, isto kao i m5.large, ali obitelj t3 je napravljena za “propusnije” mrežne aktivnosti (skokovi u CPU-u), a ne m5 obitelj izrađena za ujednačena opterećenja CPU-a.

Cijene

Posljednje što treba spomenuti prije nego što prijeđemo na pohranu je cijena. AWS je skup u usporedbi s drugim opcijama poput Digital Ocean-a. CPU (obitelj primjeraka) i pohranu (tvrdi disk) plaćate odvojeno, ovisno o tome što koristite. CPU se plaća po satu. Budući da validatori moraju biti na mreži 24 sata, možete upotrijebiti donju tablicu cijena (od prosinca 2020.) za izradu nekih grubih izračuna: 

To su cijene na zahtjev. AWS pruža nešto što se zove Cijene rezervirane instance, ako obećate da ćete imati virtualnu instancu od godine do tri godine, možete dobiti do 50-60% smanjenja troškova na gornjoj tablici cijena. (Hvala Jasonu Chromanu na ovom savjetu!)

Na početnoj stranici EC2 kliknite “Rezervirane instance” na lijevom izborniku, prikazanom u nastavku:

Kliknite “Instanca rezervirana za kupnju”:

U izbornik koji se pojavi unesite detalje o tipu instance i količinu vremena za koje želite vidjeti cijene (odabirem m5.xlarge i rok od 36 mjeseci):

Kliknite “Pretraži” i pogledajte opcije cijena:

Postoji značajan popust na cijenu, vjerujem preko 50%, ali zaključan sam na tri godine. Jednom kada kupite rezervirani primjerak, AWS ga zatim primjenjuje na postojeći virtualni okvir ili će ga primijeniti nakon pokretanja. Imajte na umu da NE uključuje prostor za pohranu (tvrdi disk). 

Napomena: Još to ne radim, jer još nisam uvjeren da je AWS najbolja opcija za pojedinca koji ulaže jedan do tri čvora validatora Ethereum 2.0. Izvodim instancu s cijenama na zahtjev kako bih vidio kako to ide prije predaje. 

Skladištenje

Vraćajući se na postupak pokretanja instance, prelazimo na karticu “Dodaj pohranu”

Sjajni tehničari s kojima sam se savjetovao preporučili su 100 GB SSD-a za opću namjenu. Pohrana obično nije usko grlo kod Eth2 klijenata. Međutim, ovo je bez pokretanje punog klijenta Eth1. Za pohranu Eth1, konzervativna pretpostavka bila bi oko 1TB. Obavezno to uzmite u obzir ako ne koristite Infuru.

Ne znam jedinicu u stupcu IOPS na gornjoj slici, ali to je ulaz-izlaz za tvrdi disk koji komunicira s CPU-om. Ovo je klasično usko grlo za potpunu sinkronizaciju čvora Eth1. Ako želite sinkronizirati puni Eth1 klijent na ovom računalu i imate problema, ovo bi moglo biti mjesto za traženje.

Luke

Preskačući “Dodavanje oznaka”, prijeđite na “Konfiguriranje sigurnosne grupe”. To su različiti otvori stvoreni za različite vrste dolazne i odlazne komunikacije s instancom.

AWS automatski otvara tradicionalni SSH priključak, jer je to glavni način interakcije s instancom. Novčić od indijskog oraščića i Somer Esat’s izvrsni vodiči preporučuju onemogućavanje pristupa lozinkom za SSH, ali vidjet ćemo kad pokrenemo instancu koja nije zadana opcija za AWS. Međutim, dobro je randomizirati svoj SSH priključak na broj između 1024-65535. Na ovaj se način sprečava zlonamjerne aktere da mrežno skeniraju standardni SSH priključak. Pogledajte kako općenito osigurati SSH priključak ovdje a posebno za AWS ovdje.

Moramo dodati dva sigurnosna pravila kako bismo mogli prilagoditi Teku klijenta, a to je povezano s peer-to-peer komunikacijom. Blockchain mreže su decentralizirane u smislu da čvorovi izravno međusobno razgovaraju. Umjesto da se savjetuje sa središnjim čvorom, pojedinačni čvor će razviti i održati razumijevanje stanja mreže “ogovaranjem” mnogih čvorova. To znači da kada se jedan klijent rukuje s drugim, oni mijenjaju podatke o mreži. Dovoljno puta s različitim čvorovima, informacije se šire mrežom. Trenutno moj čvor Eth2 Validator ima 74 vršnjaka s kojima razgovara.

Teku komunicira s drugim čvorovima na portu 9000, pa ćemo to otvoriti za UDP i TCP, dvije različite vrste komunikacijskih protokola. 

Poslije bi to trebalo izgledati otprilike ovako:

Pokretanje SSH ključeva i instanci

Na kraju, idite na “Pregled i pokretanje”, pregled donesenih izbora. Nakon odobrenja, pojavit će se skočni izbornik o SSH tipkama. Ne prikazujem svoje jer sadrže osjetljive podatke. Naime, par ključeva koji se koristi za autentifikaciju i prijavu na virtualnu instancu putem SSH-a (lokalni naredbeni redak). Ako već nemate par, AWS će ga generirati za vas. Morate ovo preuzeti i tretirati ga kao privatni ključ Ethereuma! To je jedini način povezivanja s instancom i AWS je neće sačuvati za vas.

Jednom kad se sve pokvari, pojavit će se ovaj prozor:

U redu! To je gotovo, prijeđimo na pristup i zaštitu naše instance, a zatim instaliranje i pokretanje Tekua!

Pristup Instanceu

Glavni način pristupa AWS instanci je putem SSH-a, “Kriptografski protokol za sigurno upravljanje mrežnim uslugama preko nezaštićene mreže.” Kao što je ranije spomenuto, AWS prema zadanim postavkama onemogućava provjeru autentičnosti lozinke za pristup instanci. Možete koristiti samo par ključeva generiran prije pokretanja instance. Parovi ključeva trebaju imati završenu datoteku .pem. 

AWS pruža čist način za dobivanje vaše SSH naredbe. Klikom na pokrenutu instancu s glavne EC2 stranice, u gornjem desnom dijelu nalazi se gumb koji kaže “poveži se”:

Na sljedećoj će stranici biti SSH naredba specifična za vašu instancu. Bit će strukturirano ovako:

ssh -i "PATH_TO_AWS_KEYPAIR.pem" [e-pošta zaštićena]_IDENTIFIER.compute-ZONE.amazonaws.com

Unosom ove naredbe u terminal započet će SSH sesija. Lokalni će uređaj prvi put pitati želite li vjerovati ECDSA otisku prsta koji pruža AWS. Ovo je za sprječavanje a napad čovjek u sredini i ako je zabrinut, korisnik može dobiti otisak prsta svoje instance ove korake.

U terminal odvojen od trenutne SSH sesije, prenesite datoteke ključa za provjeru valjanosti potrebne za pokretanje Tekua. U prethodnom postu na blogu prošli smo kroz ulaganje 32 ETH i dobivanje ključeva validatora za Ethereum 2.0. Na kraju nam je ostala ova struktura datoteka:

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

Moramo prenijeti datoteku validator_key_info u našu virtualnu instancu. Protokol sigurnog kopiranja (scp) omogućuje nam da to učinimo sigurno. Prilagodite donju generičku naredbu scp koristeći put do gornjeg direktorija i prethodne SSH naredbe:

scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [e-pošta zaštićena]_IDENTIFIER.compute-ZONE.amazonaws.com:~

(Primijetite “: ~” na kraju cijele naredbe.)

Trebali biste vidjeti kako dolazi do prijenosa datoteke. Ako se vratite na svoju SSH sesiju i upišete ls, trebali biste vidjeti preneseni direktorij.

Instaliranje Tekua

Sad kad imamo potrebne datoteke valjanika, instalirat ćemo Teku. Prvo moramo ažurirati postojeće programe i instalirati potrebne Java sustave:

Instalirajte Javu

sudo apt ažuriranje && sudo apt instalirati default-jre && sudo apt instalirati default-jdk

Dvostruka provjera instalirane Jave bila je uspješna sa:

java -verzija

Instalirajte Binary

Ovdje potražite najnovije stabilno izdanje Teku. Kopirajte adresu veze u datoteku tar.gz, a zatim je preuzmite iz svoje SSH sesije. Evo kako je izgledala moja, vaša će verzija najvjerojatnije biti drugačija:

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

Dekomprimirajte preuzetu datoteku sljedećom naredbom. Ako imate drugu verziju, dodajte to ime datoteke za razliku od teku-20.11.1.tar.gz:

katran -zxvf teku-20.11.1.tar.gz

Radi čistoće uklonite datoteku tar.gz.

Nakon svih ovih koraka, evo kako bi trebao izgledati vaš kućni direktorij (broj i sadržaj Teku verzije mogu se razlikovati:

ubuntu / └── teku-20.11.1 / ├── LICENCA ├── bin / ├── lib / ├── licenca-ovisnost.html ├── teku.autocomplete.sh └── validator_key_info / ├── KLJUČEVNICA -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

Stvorite korisnika koji nije root

Ovaj je korak kopiran iz Somer Esat’s izvrstan Ubuntu / Teku tutorial

Stvorit ćemo nekorenskog korisnika koji se zove teku koji može upravljati Tekuom. Upišite sljedeće:

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

Stvorit ćemo prilagođeni direktorij podataka i za Teku, a zatim ćemo tekućem korisniku dati pristup:

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

Izradite systemd uslugu

Ovaj je korak prilagođen Someru Esatu izvrstan Ubuntu / Teku tutorial

Ovaj će korak stvoriti uslugu koja će Teku raditi u pozadini. Također će omogućiti stroju da automatski ponovo pokrene uslugu ako se zaustavi iz nekog razloga. Ovo je neophodan korak da bismo provjerili radi li naš validator 24-7.

Stvorite datoteku usluge pomoću uređivača nano teksta:

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

U ovu datoteku (koja bi trebala biti prazna) stavit ćemo niz naredbi koje će systemd izvršavati kad pokrenemo uslugu. Evo donjeg koda, morat ćete dodati u sljedeće stavke koje smo prikupili tijekom ovog putovanja:

• Krajnja točka Infura Eth1 HTTP
• Staza direktorija validator_key_info s dvije važeće datoteke povezane s ključem
• Prilagođeni put podataka (lib / var / teku)

Stavite te vrijednosti u podebljani kod u nastavku, a zatim sve to kopirajte u nano uređivač teksta:

[Jedinica] Opis = Teku Beacon Node Wants = network-online.target After = network-online.target [Service] Type = simple User = teku Group = teku Restart = always 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/KEYABCD.t –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –baza podataka-put = / var / lib / teku [Instaliraj] WantedBy = višekorisnički.cilj

Upišite command-X, a zatim upišite “Y” da biste spremili promjene

Moramo ponovno pokrenuti “systemctl” da bismo ga ažurirali:

sudo systemctl daemon-reload

Pokrenite uslugu:

sudo systemctl start teku

Provjerite je li sve u redu:

sudo systemctl status teku

Ako vidite pogreške, potražite više detalja pokretanjem:

sudo journalctl -f -u teku.service

Uslugu Teku možete zaustaviti pokretanjem:

sudo systemctl stop teku

Na stranici za rješavanje problema Teku potražite uobičajene pogreške ili provjeri Teku neslogu, što nadgleda tim.

Jednom kada osjetite da su vam stvari glačane, omogućite da se usluga ponovo pokrene ako se isključi pokretanjem:

sudo systemctl omogućiti teku

Eto ti! Stvari bi se trebale kuhati upravo sada. Kada pregledavate uslugu Teku, vidjet ćete niz dnevnika koji bilježe događaj sinkronizacije, ovo je vaš validator koji sinkronizira lanac svjetionika. Jednom kad dođu do glave, ti će se dnevnici promijeniti kako bi glasili Slot Event, a vidjet ćete i izvedbu atestiranja i blokirati prijedloge.

Pokreni

Izvor: Beaconcha.in

1. prosinca u 12:00 UTC, potvrđeni su prvi blokovi Beacon Chain-a. Došao je prvi blok Validator 19026, sa zagonetnim grafitima: “Gospodin F bio je ovdje.” Dvanaest sekundi kasnije stigao je sljedeći blok, grafiti koji ukazuju na to da se validator može nalaziti u Zug, Švicarska. Lanac Eth2 Beacon lagano je rastao, blok po blok svakih 12 sekundi. Tada je uslijedila sljedeća prepreka: bi li na mreži bilo dovoljno validatora za finaliziranje prve Epohe? Da! 82,27% validatora potvrdilo je valjanost Epohe 0, poslovičnog prizemlja Beacon Chain-a. Više o pokretanju Beacon Chain-a, a što je sljedeće, možete pročitati ovdje. 

Izvor: Beaconcha.in

Sada smo na Epoch 760, što znači da Beacon Chain radi bez problema već gotovo tjedan dana. 

Evo snimka iz moje perspektive trenutka postanka, koristeći postavke opisane u ovom postu:

U sljedećem dijelu napravit ćemo pregled kako stvari idu. Pristupit ću mjernim podacima iz Tekua, razgovarati o cijeni pokretanja AWS-a i ukratko o stanju mreže.

Pratite nas!

Resursi i poveznice

Zahvaljujemo Jamesu Becku, Meredith Baxter, Jasonu Chromanu, Aaronu Davisu, Chamindi Divitotaweli, Benu Edgingtonu, The Dark Jesteru, Someru Esatu, Josephu Lubinu, Collinu Meyersu, Nicku Nelsonu, Mara Schmiedt, Adrianu Suttonu i Alexu Tudoracheu na podršci i tehničkoj pomoći.

Ethereum 2.0Newsletter Pretplatite se na naš bilten za najnovije vijesti o Ethereumu, rješenja za poduzeća, resurse za programere i još mnogo toga. Adresa e-pošte