blogul 1NewsDevelopersEnterpriseBlockchain Explained Evenimente și conferințe ApăsațiBuletine informative

Aboneaza-te la newsletter-ul nostru.

Adresa de email

Vă respectăm confidențialitatea

AcasăBlogDezvoltatori

Călătoria mea spre a deveni validator pe Ethereum 2.0, partea 2

Care sunt câteva lucruri pe care ar trebui să le luați în considerare atunci când alegeți hardware și software pentru a rula un client validator Ethereum 2.0? De Coogan Brennan 5 decembrie 2020 Postat pe 5 decembrie 2020

Călătoria mea pentru a deveni validator pe Ethereum 2 0 Partea 2

Notă: puteți deveni în continuare validator în rețeaua Ethereum 2.0! Va exista un timp de așteptare pentru a fi activat ca validator – începând cu 4 decembrie 2020, timpul de așteptare este aproximativ 9,9 zile. Vedeți pașii pentru a juca în partea 1 a acestei serii.

  1. Declinare de responsabilitate
  2. Introducere
  3. Considerații privind configurarea validatorului
  1. Hardware pentru verificarea viitorului
  2. Pentru a rula sau a nu rula un client Eth1?
  3. Gazduire virtuala vs locala
  4. Alegerea clientului Eth2 și evitarea penalităților
  • Configurarea instanței AWS
    1. Sistem de operare
    2. Prețuri
    3. Depozitare
    4. Porturi
    5. Taste SSH și lansare instanță
    6. Instalarea Teku
      1. Cerințe
      2. Instalați binar
      3. Creați un utilizator non-root
      4. Creați un serviciu systemd
      5. Lansa
      6. Declinare de responsabilitate

        Acesta este un post pe care îl scriu ca angajat al ConsenSys și ca cineva care intenționează să participe la lanțul de balize. Fosta declarație înseamnă că prioritizez produsele ConsenSys (produsele ConsenSys sunt de obicei cele mai bune din clasă pentru Ethereum și am și acces la echipe de ingineri care mă pot ajuta să răspund la întrebări și să depanez). Această ultimă afirmație înseamnă că optimizez pentru costuri și ușurință în utilizare: nu am mii de ETH pentru a oferi recompense substanțiale, așa că iau câteva comenzi rapide. Acestea sunt deciziile pe care le-am luat pentru a face ca miza pe Ethereum 2.0 să fie cât mai simplă și accesibilă pentru persoanele fizice, dar să vină cu compromisuri pentru descentralizare și confidențialitate. Cu toate acestea, puteți urmări cursele generale ale tutorialului de mai jos și puteți face diferite alegeri. De fapt, dacă poți face asta, te-aș încuraja! 

        În sfârșit, participarea la Ethereum 2.0 este extrem de experimentală și implică un angajament pe termen lung (aloc trei ani). Vă rugăm să nu participați dacă nu vă simțiți confortabil cu un nivel ridicat de risc însoțitor, cu ceva încă în curs de dezvoltare. Dacă nu sunteți sigur dacă ar trebui să mizați, vă rugăm să vă înscrieți la Discordia ConsenSys și întrebați pe canalul # teku-public. 

        Introducere

        În postarea anterioară, am discutat motivele desfășurării Ethereum 2.0 și am parcurs miza 32 ETH în Ethereum 1.0 Mainnet Deposit Contract. Am atins generarea cheie și modul în care se desfășoară procesul de miză Platforma de lansare leagă Ethereum 1.0 la 2.0.

        Pe 23 noiembrie, a fost îndeplinită cantitatea minimă de ETH mizat pentru a lansa Ethereum 2.0 – aproximativ 524.288. Oamenii pot continua să participe la contract, iar numărul validatorilor a crescut la peste 33.000 începând cu 4 decembrie.

        Aaron Davis al MetaMask își împărtășește gândurile în canalul intern de mize ConsenSys Slack 

        Deși a fost extrem de interesant să intru în blocul Genesis ca validator, câteva secunde mai târziu am avut o experiență similară cu colegul meu Aaron Davis în canalul nostru intern de mize ConsenSys: la ce sarcină nebună mă înscrisem? Din fericire, am acces la oameni incredibil de strălucitori și tehnici suficient de caritabili pentru a oferi acestei rubrici câteva sfaturi, indicii și informații despre rularea infrastructurii de mize. Sper să transmit o parte din acel sfat valoros aici oricărei alte părți interesate.

        Aceasta va fi prima parte a acestui articol: Care sunt câteva lucruri pe care ar trebui să le luați în considerare atunci când alegeți hardware și software pentru a rula un client validator Ethereum 2.0? A doua parte va parcurge combinația specifică hardware / software pe care am ales-o pentru clientul meu validator. Alegerile pe care le faceți pentru configurația dvs. vor depinde de resursele dvs., de înclinația personală și de capacitatea tehnică. Voi face tot posibilul pentru a evidenția modul în care prejudecățile și circumstanțele personale au informat alegerile mele.

        În sfârșit, înainte de a intra în el, vreau să reiterez că aceste postări sunt aproape ca intrări de jurnal pentru experiența mea care mizează 32 ETH (deși intrări de jurnal cu aspecte tehnice extinse). Ca atare, s-ar putea să îmi schimb puțin abordarea pe măsură ce lanțul de balize progresează. De exemplu, m-am gândit că voi folosi cu siguranță AWS. După cum veți citi mai jos, mă gândesc acum la asta. De asemenea, voi fi foarte clar cu privire la elementul financiar al mizei. Miza este o modalitate de a sprijini ecosistemul Ethereum, dar pentru o utilizare publică durabilă, ar trebui, de asemenea, să fie accesibilă și posibilă pentru persoanele care dețin ETH să o facă.. 

        Hardware pentru verificarea viitorului

        Cerințele de bază pentru rularea unui validator astăzi sunt relativ ușor de satisfăcut. Mara Schmiedt și Collin Meyers Ghid validator pe Bankless are un rezumat bun de cerințe minime. Cel mai provocator aspect al determinării echipamentului de validare Ethereum 2.0 este echilibrarea nevoilor actuale ale fazei 0 a lanțului Beacon cu orice cerințe viitoare necunoscute în prezent, pe măsură ce dezvoltarea continuă. (Aceasta nu este o problemă dacă vă simțiți confortabil să urmăriți atent validatorul și puteți să abordați rapid și ușor modificările) 

        Ben Edgington, manager de proiect Teku și editor al Eth2.news, mi-a oferit câteva cazuri marginale în care rețeaua ar putea cere mai mult clientului validator. Pe termen scurt, cea mai mare preocupare ar fi ceva de genul incidentul serverului de timp Medalla, în care o eroare și o remediere ulterioară în clientul Prysm au oprit finalizarea pe testnet (aproximativ vorbind, rețeaua nu putea „produce blocuri”). Deoarece nu a existat nicio finalitate în rețea (nu există „blocuri confirmate”), validatorii au trebuit să dețină mai multe tranzacții în memoria RAM decât în ​​mod normal. 

        Mașinile cu 8 GB RAM – care ar fi fost mai mult decât suficient în condiții normale – au început să întâmpine probleme de „lipsă de memorie” care ar fi putut duce la reducere. O creștere ca aceasta, deși neobișnuită, nu este exclusă pentru faza 0 mainnet.

        Viitoarele ambiguități de configurare pentru rețea sunt fuziunea Ethereum 1.0 și 2.0 și introducerea sharding-ului. Încă nu știm când se vor întâmpla aceste fuziuni sau exact ce vor necesita. Aș dori să am o bază puternică a procesorului care intră în faza 0 (4 nuclee virtuale, 16 GB RAM cu 100 GB SSD) și apoi să-mi concentrez atenția pentru viitoarele ajustări în jurul spațiului de stocare (lăsând spațiu aici). Vă rugăm să rețineți că acest lucru se poate dovedi excesiv și poate consuma recompense de miză.

        Acestea sunt „necunoscutele cunoscute” ale viitorului, să discutăm astăzi principalele puncte de decizie de configurare pentru validatori.

        Pentru a rula sau a nu rula un client Eth1?

        Este un rit de trecere pe care încerc să-l supun pe studenții noștri bootcamp cât mai des posibil: sincronizarea unui client Ethereum 1.0. Este un secret deschis că găzduirea unui nod Ethereum 1.0 „complet” este mai degrabă un act de dragoste decât o soluție întărită, Dilemma prizonierului. „Complet” trebuie pus în ghilimele, deoarece chiar și dezvoltatorilor de bază Ethereum le este greu să cadă de acord asupra unei definiții a ceea ce înseamnă de fapt „nod complet”.

        Un lucru pe care putem fi de acord cu toții: este nevoie de mai mult timp și spațiu de stocare pentru a sincroniza un client Ethereum 1.0 decât v-ați imagina. Validatorii noștri trebuie să aibă un mod de a interoga baza de date a rețelei Ethereum 1.0 (vom afla mai târziu de ce). Dacă doriți să economisiți spațiul și durerea de cap de sincronizare la nivel local, puteți utiliza un punct final Infura, care este disponibil gratuit cu înregistrare. 

        Chiar dacă acest lucru economisește depozitare semnificativă și îngrijorare logistică, sacrifică o anumită cantitate de descentralizare pentru rețelele Eth1 și Eth2 simultan. Dacă Infura ar coborî, care este extrem de rar, dar are loc, care ar provoca un efect de ondulare peste validatorii Ethereum 2.0 care îl utilizează pentru punctul lor final Ethereum 1.0. Ceva de luat în considerare!

        (Doar pentru a fi clar: dificultatea sincronizării unui nod complet Ethereum are legătură cu natura statului mondial Ethereum, nu cu dezvoltatorii de bază Ethereum 1.0 care au făcut o treabă uimitoare rezolvând această problemă extrem de provocatoare.)

        Gazduire virtuala vs locala

        Următorul aspect pentru mine a fost găzduirea unui nod validator local (acasă) sau virtual (pe un furnizor de servicii virtuale precum Amazon Web Services (AWS), Digital Ocean etc.). Așa cum am menționat în piesa anterioară, nu am încredere în mine că voi rula un nod de validare consistent de acasă, chiar și pe un laptop vechi stocat undeva. Stângace și tâmpit, fie l-aș da peste picior, fie uit de el.

        Optez pentru a-mi rula nodul pe AWS, pentru că asta este cel mai cunoscut (Cu toate acestea, după ce am parcurs tot acest proces, ghicesc această decizie. Voi discuta despre asta mai târziu). Compensarea aici este din nou descentralizarea: dacă AWS scade sau are probleme (la fel ca recent), Sunt la mila lor. Dacă suficientă lume rulează noduri pe AWS, aceasta poate afecta rețeaua Ethereum mai mare.

        Oamenii probabil se vor auto-selecta pentru aceasta. Găzduirea locală este un tip special de proiect și nu toată lumea are timpul, resursele sau angajamentul necesar. În timp ce găzduirea virtuală este o forță centralizatoare, am optat să merg cu ea datorită ușurinței sale de utilizare și (sperăm) ca durata de funcționare să fie garantată. 

        Dacă doriți să rulați un nod validator local, puteți urmări în continuare direcția generală a acestui tutorial, Seria excelentă de tutoriale Somer Esat cu clienți diferiți sau sincronizați chiar și un Raspberry Pi Model 4B cu 8 GB RAM cu Ethereum pe ARM. (Sincronizarea pe Raspberry Pi este încă foarte experimentală și oamenii ar trebui să aștepte până când Ethereum din echipa ARM confirmă stabilitatea acesteia)

        Alegerea clientului Eth2 și evitarea penalităților

        O altă alegere majoră este clientul Ethereum 2.0 dintre clienții existenți: Far, Lodestar, Nimbus, Prisma și Teku. Sunt puternic părtinitor față de Teku și nu sunt suficient de priceput pentru a dezbate punctele mai fine ale clienților. Acest articol este o imagine de ansamblu decentă a performanței clienților pe Medalla. (Rețineți că Medalla a cerut mult mai mult de la procesoare decât va face mainnet.)

        Dovada mizei încorporează descurajări explicite pentru a încuraja un comportament corect în rețea. Acestea iau forma validatorilor dinging pentru a fi offline și a mișcării mai dramatice a actorilor slashing pentru a lua măsuri rău intenționate împotriva rețelei, în cunoștință de cauză sau altfel.

        Cea mai frecventă problemă va fi să vă asigurați că validatorul dvs. este disponibil pentru rețea. Aceasta înseamnă să vă asigurați că validatorul dvs. este online. Există abordarea DevOps pentru această problemă – crearea sistemului de monitorizare și alertare pentru a vă avertiza dacă validatorul dvs. este offline – pe care nu îl voi acoperi aici.

        Dar există o altă modalitate de a nu fi disponibil pentru rețea și asta dacă clientul dvs. începe să se comporte greșit dintr-un motiv sau altul. După eroarea serverului de timp a provocat o încetinire a rețelei pe Medalla, dezvoltatorii de bază Eth2 s-au reunit pentru a se dezvolta „[A] formatul standard pentru transferul istoricului semnării unei chei permite validatorilor să comute cu ușurință între clienți fără riscul de a semna mesaje conflictuale.” Nu toți clienții au această protecție, dar Teku are. Aici puteți citi despre utilizarea protecției Slash Teku (rulează implicit), inclusiv migrarea între nodurile Teku sau un nod non-Teku către nodul Teku.

        Dacă aveți probleme cu clientul dvs. și trebuie să reporniți întreaga rețea, trebuie să fiți conștienți de subiectivitatea slabă. Dovada de lucru permite oricui să se întoarcă la blocul de geneză al rețelei și să construiască de la zero starea rețelei. Dovada mizei are totuși o captură în acest sens: dacă o treime din validatorii de rețea la un anumit punct de ieșire continuă să semneze blocuri și atestare, aceștia pot modifica starea rețelei și pot alimenta acele date false către un nod care se sincronizează cu rețea dacă actorii rău intenționați prind nodul de sincronizare înainte ca nodul de sincronizare să ajungă acolo unde validatorii și-au retras fondurile. Puteți citi mai multe despre aceasta aici, dar răspunsul scurt este că trebuie să aveți fie un „punct de control al subiectivității slab”, fie un fișier de stare codificat, în esență o arhivă a rețelei. Teku oferă steaguri de pornire pentru ambele.

        Ultima problemă de penalizare este cea mai gravă: Slashing. Slashing apare atunci când un staker lucrează împotriva regulilor rețelei. Este diferit de a fi penalizat de a fi offline. Lucrează activ împotriva rețelei prin trimiterea informațiilor de validare conflictuale. Există câteva materiale foarte bune pentru a afla mai multe despre tăiere și cum să o preveniți:

        Principala plată este să nu rulați o cheie de validare pe mai mulți clienți. Aparent, aceasta a fost cea care a provocat primul eveniment slashing vreodată, care a avut loc pe 2 dec. De atunci au existat mai multe tăieri! Dacă migrați de la o instanță la alta, verificați de patru ori că nu veți avea două mașini care funcționează de la aceeași cheie:

        Papa Ben o spune așa cum este. Sursă

        Specificații de configurare AWS + Infura + Teku Validator

        Configurarea blocului meu Genesis:

        Sistem de operare: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

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

        Memorie: 4 nuclee virtuale, 16 GB RAM (Amazon Web Service)

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

        Client Ethereum 1.0: Infura endpoint (nivel gratuit)

        Client Ethereum 2.0: Teku

        Privind prin toate considerațiile de mai sus, nu eram sigur de cea mai bună abordare pentru construirea unui set de validare. Pentru mine, aș dori să aleg o mașină și, în general, nu mă îngrijorez să o schimb pe cel puțin doi ani. Acest lucru ajută la costul global al validatorului (pot obține o reducere semnificativă dacă mă conectez la un furnizor virtual timp de câțiva ani) și nu sunt deosebit de agil cu serverele care se învârt. Această abordare de prevenire a viitorului sau „supra-specificați”, sperăm că îmi ușurează viața în următorii doi ani.

        Inițial, eram încrezător că AWS este cea mai bună platformă virtuală și este serviciul pe care îl voi folosi pentru această postare și următoarea. Cu toate acestea, după ce am parcurs întregul proces, mi-am dat seama că AWS ar putea fi excesiv pentru dezvoltatorul individual. Puterea reală a AWS pare să fie capacitatea sa de a se extinde dinamic pentru a satisface cererea care are un cost premium. Acest lucru are sens economic pentru un proiect la scară largă, la nivel de întreprindere, dar Ethereum 2.0 individual actual cerințele clienților nu necesită o astfel de rigoare.

        Voi continua cu AWS, dar am și opțiunea de a rula o instanță pe Digital Ocean, care ar putea fi mai potrivită pentru un dezvoltator individual. Mai multe despre asta la o dată ulterioară.

        Configurați contul Infura

        Aleg să folosesc Infura ca obiectiv final Ethereum 1.0. Deocamdată, lanțul de balize urmărește Contractul de depozit pe Ethereum 1.0 pentru a activa noii jucători atunci când au depus în mod corespunzător 32 ETH și au depus semnături BLS.

        În viitor, lanțul de balize va începe testarea procesării ulterioare, începând să utilizeze informațiile de stat de la Ethereum 1.0 pentru a crea puncte de control paralele pe lanțul de balize.

        După cum am menționat mai sus, există două modalități principale de a avea vizibilitate în rețeaua Ethereum 1.0. Una este sincronizarea și menținerea activă a unui nod Ethereum 1.0, care creează o bază de date de stat locală Ethereum 1.0. Cealaltă este utilizarea unui serviciu precum Infura, care oferă un punct final Ethereum 1.0 ușor, accesibil prin HTTPS sau WebSockets.

        Conectați-vă pentru un cont aici. După ce aveți un cont, faceți clic pe sigla Ethereum din partea stângă.

        Faceți clic pe „Creați un proiect nou” în colțul din dreapta sus

        Denumiți-vă proiectul (al meu este „Eth 2 Validator”) și accesați „Setări”, asigurați-vă că punctele finale ale rețelei sunt „Mainnet” și copiați punctul final HTTPS:

        Vom folosi acest lucru mai târziu pentru comanda de pornire a clientului Teku!

        Configurarea instanței AWS

        Configurarea unei instanțe EC2 pe Amazon este simplă. Vom avea câteva modificări ici și colo pentru a ne ajuta instanța virtuală să se joace bine cu Teku.

        Creați un cont AWS (diferit de un cont Amazon.com) și conectați-vă la AWS Console. Accesați pagina EC2, care va arăta cam așa:

        Faceți clic pe butonul „Lansați instanța”. Veți vedea apoi următorul ecran:

        Sistem de operare

        Aici selectăm ce imagine a mașinii (despre care consider că este un sistem de operare) pe care am dori să o folosim în instanța noastră virtuală. Selectez Ubuntu Server 20.04, care este un mediu server Linux. Mediul Ubuntu Server are câteva diferențe cheie de optimizare față de mediul Ubuntu Desktop. Principala diferență pentru scopurile noastre este că Ubuntu Server nu are o interfață grafică de utilizator (GUI). Unde mergem, există doar o linie de comandă! Mă aduce înapoi în zilele mele Apple II.

        După selectarea sistemului de operare, alegem tipul instanței noastre:

        Mi se pare destul de copleșitor acest meniu, așa că am să-l descompun puțin pentru tine. Aici selectăm nucleul de calcul / puterea RAM / CPU pentru echipamentul nostru. Este „memoria brută” sau „memoria activă” a aparatului și separată de stocarea (hard disk) a unui dispozitiv. Gândiți-vă la acesta ca la motorul instanței noastre virtuale, pe care vom rula sistemul nostru de operare Ubuntu Server. AWS le separă în familii de instanțe separate notate prin combinația literă / număr din coloana din stânga.

        Familiile de instanțe au aranjamente hardware diferite, la fel cum diferite motoare auto au configurații diferite de pistoane, prize și combustibili pentru a satisface cerințe diferite. Ne vom concentra pe două dintre familiile lor de instanțe de „calcul general”, m5 și t3.

        Selectez instanța m5.xlarge, care oferă 4 nuclee virtuale de calcul (vCPU) și 16 GB RAM. După ce am rulat Ethereum 2.0 mainnet timp de aproximativ o zi, mașina mea nu a folosit mai mult de 4% din vCPU disponibil. Așa cum s-a menționat în secțiunea „Viitoare de verificare” de mai sus, cererile rețelei Ethereum 2.0 vor crește doar. Dar pentru următoarele câteva luni, în absența unor vârfuri de rețea majore prelungite, cel mai probabil aș fi în regulă cu o instanță m5.large (2 nuclee virtuale / vCPU-uri, 8 GB RAM)

        Oamenii tehnici mai pricepuți decât mine au recomandat, de asemenea, instanța t3.large ca opțiune rezonabilă pentru Ethereum 2.0. t3.large are 2 vCPU-uri și memorie de 8 GB, la fel ca m5.large, dar familia t3 este construită pentru o activitate de rețea mai „spargătoare” (vârfuri în CPU), mai degrabă decât familia m5 construită pentru încărcări consistente de CPU.

        Prețuri

        Ultimul lucru de menționat înainte de a trece la stocare este prețul. AWS este scump în comparație cu alte opțiuni precum Digital Ocean. Plătiți CPU (familia instanței dvs.) și spațiul de stocare (hard disk-ul) separat în funcție de ceea ce utilizați. Procesorul se plătește pe oră. Deoarece validatorii trebuie să fie online 24 de ore, puteți utiliza tabelul de prețuri de mai jos (din decembrie 2020) pentru a face câteva calcule aproximative: 

        Acestea sunt prețuri la cerere. AWS oferă ceva numit Prețuri rezervate pentru instanțe, dacă promiteți să aveți o instanță virtuală de la un an la trei ani, puteți obține o reducere a costurilor cu până la 50-60% în tabelul de prețuri de mai sus. (Mulțumesc lui Jason Chroman pentru acest sfat!)

        Din pagina de pornire EC2, faceți clic pe „Instanțe rezervate” din meniul din stânga, prezentat mai jos:

        Faceți clic pe „Cumpărați o instanță rezervată”:

        În meniul care apare, introduceți detaliile tipului de instanță și perioada de timp dorită pentru a vedea prețul (aleg m5.xlarge și un termen de 36 de luni):

        Faceți clic pe „Căutare” și vedeți opțiunile de preț:

        Cred că există o reducere semnificativă a prețului, peste 50%, dar sunt blocat timp de trei ani. Odată ce ați achiziționat instanța rezervată, AWS o aplică unei cutii virtuale existente sau o va aplica odată ce este lansată. Nu uitați că acest lucru NU include spațiu de stocare (hard disk). 

        Notă: încă nu fac acest lucru, deoarece nu sunt încă convins că AWS este cea mai bună opțiune pentru un individ care mizează unul până la trei noduri de validare Ethereum 2.0. Rulez o instanță cu prețuri la cerere pentru a vedea cum merge înainte de a comite. 

        Depozitare

        Revenind la procesul de lansare a instanței, trecem la fila „Adăugați spațiu de stocare”

        Persoanele tehnice strălucite pe care le-am consultat mi-au recomandat o cantitate de stocare de 100 GB SSD cu scop general. Stocarea nu este de obicei un obstacol pentru clienții Eth2. Cu toate acestea, acesta este fără rularea unui client Eth1 complet. Pentru stocarea Eth1, o estimare conservatoare ar fi de aproximativ 1 TB. Asigurați-vă că țineți cont de acest lucru dacă nu utilizați Infura.

        Nu cunosc unitatea de pe coloana IOPS din imaginea de mai sus, dar este intrarea-ieșirea pentru unitatea de disc care comunică cu CPU. Acesta este un blocaj clasic pentru sincronizarea completă a nodului Eth1. Dacă doriți să sincronizați un client Eth1 complet pe această mașină și aveți probleme, acesta ar putea fi un loc de căutare.

        Porturi

        Trecând peste „Adăugați etichete”, treceți la „Configurați grupul de securitate”. Acestea sunt diferitele deschideri create pentru diferite tipuri de comunicare de intrare și ieșire cu instanța.

        AWS deschide automat portul tradițional SSH, deoarece acesta este principalul mod în care vom interacționa cu instanța. Monedă caju și Somer Esat’s ambele ghiduri recomandă ambele dezactivarea accesului la parolă pentru SSH, dar vom vedea când vom lansa instanța care nu este opțiunea implicită pentru AWS. Cu toate acestea, este bine să vă randomizați portul SSH la un număr între 1024-65535. Aceasta este pentru a preveni ca actorii rău intenționați să scaneze în rețea portul SSH standard. Vedeți cum să vă securizați portul SSH în general Aici și în special pentru AWS Aici.

        Trebuie să adăugăm două reguli de securitate pentru a găzdui clientul Teku și are legătură cu comunicarea de la egal la egal. Rețelele blockchain sunt descentralizate în sensul că nodurile vorbesc direct între ele. În loc să consulte un nod central, un nod individual va dezvolta și menține o înțelegere a stării rețelei prin „bârfă” cu multe noduri. Aceasta înseamnă că atunci când un client strânge mâinile cu altul, schimbă informații despre rețea. Efectuat de suficiente ori cu diferite noduri, informațiile se propagă în întreaga rețea. În prezent, nodul meu Eth2 Validator are 74 de peeri cu care conversează.

        Teku comunică cu alte noduri de pe portul 9000, așa că o vom deschide pentru UDP și TCP, două tipuri diferite de protocoale de comunicații. 

        Ulterior, ar trebui să arate cam așa:

        Taste SSH și lansare de instanță

        În cele din urmă, accesați „Examinați și lansați”, o prezentare generală a alegerilor făcute. Odată aprobat, va apărea un meniu pop-up despre cheile SSH. Nu o afișez pe a mea, deoarece conține informații sensibile. Și anume, perechea de taste utilizată pentru autentificarea și autentificarea la instanța virtuală prin SSH (linie de comandă locală). Dacă nu aveți deja o pereche, AWS va genera una pentru dvs.. Trebuie să descărcați acest lucru și să îl tratați ca pe o cheie privată Ethereum! Este singura modalitate de conectare la instanța dvs., iar AWS nu o va salva pentru dvs..

        Odată ce totul este hunky-dory, va apărea această fereastră:

        Bine! Acest lucru a fost făcut cu, să trecem la accesarea și securizarea instanței noastre, apoi instalarea și rularea Teku!

        Accesarea instanței

        Principalul mod de a accesa instanța AWS este prin SSH, „Un protocol criptografic pentru operarea în siguranță a serviciilor de rețea într-o rețea nesecurizată.” După cum sa menționat anterior, AWS dezactivează implicit autentificarea parolei pentru accesarea instanței. Puteți utiliza doar perechea de taste generată înainte de lansarea instanței. Perechea de taste trebuie să aibă un fișier.pem care se termină. 

        AWS oferă o modalitate curată de a obține comanda SSH. Dând clic pe instanța care rulează de pe pagina principală EC2, există un buton în partea dreaptă sus care spune „conectare”:

        În pagina următoare va fi o comandă SSH specifică pentru instanța dvs. Va fi structurat astfel:

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

        Introducerea acestei comenzi într-un terminal va începe sesiunea SSH. Prima dată, mașina locală vă va întreba dacă doriți să aveți încredere în amprenta ECDSA furnizată de AWS. Aceasta este pentru a preveni o atac om-la-mijloc și, dacă este îngrijorat, un utilizator poate obține urmele amprentei instanței acești pași.

        Într-un terminal separat de sesiunea SSH curentă, transferați fișierele cheie de validare necesare pentru a rula Teku. În postarea anterioară de pe blog, am parcurs miza 32 ETH și obținem chei de validare pentru Ethereum 2.0. La final, am rămas cu această structură de fișiere:

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

        Trebuie să transferăm fișierul validator_key_info în instanța noastră virtuală. Secure Copy Protocol (scp) ne permite să facem acest lucru în siguranță. Adaptați comanda scp generică de mai jos folosind calea către directorul de mai sus și comanda SSH anterioară:

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

        (Rețineți „: ~” la sfârșitul întregii comenzi.)

        Ar trebui să vedeți un transfer de fișiere. Dacă navigați înapoi la sesiunea SSH și introduceți ls, ar trebui să vedeți directorul transferat.

        Instalarea Teku

        Acum, că avem fișierele de validare de care avem nevoie, vom instala Teku. În primul rând, trebuie să actualizăm programele existente și să instalăm sistemele Java necesare:

        Instalați Java

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

        Verificarea dublă a instalării Java a avut succes cu:

        java -versiune

        Instalați Binary

        Găsiți cea mai recentă versiune stabilă Teku aici. Copiați adresa link-ului în fișierul tar.gz, apoi din sesiunea SSH, descărcați-o. Iată cum arăta a mea, versiunea dvs. va fi, probabil, diferită:

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

        Decomprimați fișierul descărcat cu următoarea comandă. Dacă aveți o versiune diferită, introduceți numele fișierului respectiv spre deosebire de teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Pentru curățenie, eliminați fișierul tar.gz.

        După toți acești pași, iată cum ar trebui să arate directorul dvs. de acasă (numărul și conținutul versiunii Teku pot fi diferite:

        ubuntu / └── teku-20.11.1 / ├── LICENȚĂ ├── bin / ├── lib / ├── license-dependency.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

        Creați un utilizator non-root

        Acest pas este copiat din Somer Esat excelent tutorial Ubuntu / Teku

        Vom crea un utilizator non-root numit teku care poate opera Teku. Tastați următoarele:

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

        Vom crea și un director de date personalizat pentru Teku, apoi vom acorda utilizatorului teku acces la acesta:

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

        Creați un serviciu systemd

        Acest pas este adaptat de la Somer Esat excelent tutorial Ubuntu / Teku

        Acest pas va face un serviciu care va rula Teku în fundal. De asemenea, va permite aparatului să repornească automat serviciul dacă se oprește din anumite motive. Acesta este un pas necesar pentru a ne asigura că validatorul nostru rulează 24-7.

        Creați fișierul de serviciu utilizând editorul de text nano:

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

        În acest fișier (care ar trebui să fie gol), vom introduce o serie de comenzi pentru ca sistemul să fie executate atunci când pornim serviciul. Iată codul de mai jos, va trebui să introduceți următoarele elemente pe care le-am colectat pe parcursul acestei călătorii:

        • Infura Eth1 HTTP Endpoint
        • calea directorului validator_key_info cu două fișiere valide legate de cheie
        • Calea de date personalizată (lib / var / teku)

        Puneți acele valori în codul aldinat de mai jos, apoi copiați-le pe toate în editorul de text nano:

        [Unitate] Descriere = Teku Beacon Node Wants = network-online.target After = network-online.target [Service] Type = simplu 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/KEYSTORE-KE_7 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –baza de date-cale = / var / lib / teku [Instalați] WantedBy = multi-user.target

        Tastați comanda-X, apoi tastați „Y” pentru a salva modificările

        Trebuie să repornim „systemctl” pentru a-l actualiza:

        sudo systemctl daemon-reload

        Porniți serviciul:

        sudo systemctl start teku

        Verificați pentru a vă asigura că începe bine:

        sudo systemctl status teku

        Dacă vedeți erori, obțineți mai multe detalii executând:

        sudo journalctl -f -u teku.service

        Puteți opri serviciul Teku executând:

        sudo systemctl stop teku

        Verificați pagina de depanare Teku pentru erori frecvente sau verificați discordia Teku, care este monitorizat de echipă.

        După ce simțiți că aveți lucruri rezolvate, activați serviciul pentru a reporni dacă se oprește executând:

        sudo systemctl activate teku

        Iată-l! Lucrurile ar trebui să se pregătească chiar acum. Când inspectați serviciul Teku, veți vedea o serie de jurnale care notează un eveniment de sincronizare, acesta este validatorul dvs. care sincronizează lanțul de balize. Odată ce ajunge la cap, acele jurnale se vor schimba pentru a citi Slot Event și veți vedea, de asemenea, performanța atestării și veți bloca propunerile.

        Lansa

        Sursa: Beaconcha.in

        Pe 1 decembrie la ora 12:00 UTC, primele blocuri ale Beacon Chain au fost validate. Primul bloc a venit de la Validator 19026, cu enigmaticul graffiti, „Domnul F a fost aici”. Douăzeci de secunde mai târziu a venit următorul bloc, graffiti care indică validatorul ar putea fi localizat Zug, Elveția. Lanțul de balize Eth2 a crescut constant, bloc cu bloc la fiecare 12 secunde. Apoi a venit următorul obstacol: ar fi destui validatori online pentru a finaliza prima Epocă? Da! 82,27% dintre validatori au atestat validitatea Epocii 0, parterul proverbial al lanțului Beacon. Puteți citi mai multe despre lansarea Beacon Chain și despre ce urmează, aici. 

        Sursa: Beaconcha.in

        Suntem acum la Epoch 760, ceea ce înseamnă că lanțul Beacon funcționează fără probleme de aproape o săptămână. 

        Iată o fotografie din perspectiva mea a momentului genezei, folosind configurarea descrisă în această postare:

        În următoarea tranșă, vom face o recapitulare a modului în care merg lucrurile. Voi accesa valorile de la Teku, voi discuta despre costul executării AWS și voi discuta pe scurt starea rețelei.

        Rămâneți aproape!

        Resurse și linkuri

        Mulțumesc lui 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 și Alex Tudorache pentru sprijin și asistență tehnică.

        Newsletter Ethereum 2.0 Abonați-vă la newsletter-ul nostru pentru cele mai recente știri Ethereum, soluții pentru întreprinderi, resurse pentru dezvoltatori și multe altele.

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