blog 1AktualnościDevelopersEnterpriseBlockchain ExplainedWydarzenia i konferencjePrasaBiuletyny

Zapisz się do naszego newslettera.

Adres e-mail

Szanujemy twoją prywatność

HomeBlogDevelopers

Moja podróż do zostania walidatorem w Ethereum 2.0, część 2

Jakie kwestie należy wziąć pod uwagę przy wyborze sprzętu i oprogramowania do uruchomienia klienta walidatora Ethereum 2.0? Autor: Coogan Brennan 5 grudnia 2020 r. Opublikowany 5 grudnia 2020 r.

Moja droga do zostania walidatorem w Ethereum 2 0 Część 2


Uwaga: nadal możesz zostać walidatorem w sieci Ethereum 2.0! Będzie czas oczekiwania na aktywację jako walidator – od 4 grudnia 2020 r. Czas oczekiwania wynosi mniej więcej 9,9 dni. Zobacz kroki do obstawiania w części 1 tej serii.

  1. Zrzeczenie się
  2. Wprowadzenie
  3. Uwagi dotyczące konfiguracji walidatora
  1. Sprzęt sprawdzający przyszłość
  2. Uruchomić lub nie uruchomić klienta Eth1?
  3. Hosting wirtualny a lokalny
  4. Wybór klienta Eth2 i unikanie kar
  • Konfigurowanie instancji AWS
    1. System operacyjny
    2. cennik
    3. Przechowywanie
    4. Porty
    5. Klucze SSH i uruchamianie instancji
    6. Instalowanie Teku
      1. Wymagania
      2. Zainstaluj plik binarny
      3. Utwórz użytkownika innego niż root
      4. Utwórz usługę systemową
      5. Uruchomić
      6. Zrzeczenie się

        To jest post, który piszę jako pracownik ConsenSys i ktoś, kto planuje postawić na łańcuch beacon. Pierwsze stwierdzenie oznacza, że ​​priorytetowo traktuję produkty ConsenSys (produkty ConsenSys są zazwyczaj najlepsze w swojej klasie dla Ethereum, mam również dostęp do zespołów inżynierów, które mogą pomóc mi odpowiedzieć na pytania i rozwiązać problemy). To drugie stwierdzenie oznacza, że ​​optymalizuję koszty i łatwość użycia: nie mam tysięcy ETH, aby przynieść znaczne korzyści, więc idę na skróty. Są to decyzje, które podjąłem, aby stawianie na Ethereum 2.0 było tak proste i dostępne dla osób fizycznych, jak to tylko możliwe, ale z kompromisem w zakresie decentralizacji i prywatności. Możesz jednak postępować zgodnie z ogólnymi obrysami poniższego samouczka i dokonywać różnych wyborów. W rzeczywistości, jeśli możesz to zrobić, zachęcam cię do tego! 

        Wreszcie, obstawianie w Ethereum 2.0 jest wysoce eksperymentalne i wiąże się z długoterminowym zaangażowaniem (przeznaczam na to trzy lata). Nie bierz udziału, jeśli nie czujesz się komfortowo z wysokim poziomem ryzyka związanego z czymś, co jest nadal w fazie rozwoju. Jeśli nie masz pewności, czy powinieneś postawić, dołącz do ConsenSys discord i zapytaj na kanale # teku-public. 

        Wprowadzenie

        W poprzednim poście omówiliśmy przyczyny wdrożenia Ethereum 2.0 i omówiliśmy obstawianie 32 ETH w umowie depozytowej sieci głównej Ethereum 1.0. Poruszyliśmy temat generowania kluczy i tego, jak przebiega proces obstawiania Wyrzutnia łączy Ethereum 1.0 z 2.0.

        23 listopada minimalna kwota postawiona na ETH do uruchomienia Ethereum 2.0 – około 524 288 – została osiągnięta. Ludzie mogą nadal uczestniczyć w kontrakcie, a liczba walidatorów wzrosła do ponad 33 000 od 4 grudnia.

        Aaron Davis z MetaMask dzieli się swoimi przemyśleniami na wewnętrznym kanale obstawiania ConsenSys Slack 

        Chociaż wejście do bloku Genesis jako walidator było niezwykle ekscytujące, kilka sekund później miałem podobne doświadczenie do mojego kolegi Aarona Davisa na naszym wewnętrznym kanale obstawiania ConsenSys: Do jakiego szalonego zadania się zapisałem? Na szczęście mam dostęp do niesamowicie błyskotliwych i technicznych ludzi na tyle charytatywnych, aby udzielić temu rube kilku wskazówek, wskazówek i spostrzeżeń na temat prowadzenia infrastruktury do obstawiania. Mam nadzieję, że ułamek tej cennej rady przekażę tutaj innym zainteresowanym stronom.

        Oto, czym będzie pierwsza część tego artykułu: Jakie kwestie należy wziąć pod uwagę przy wyborze sprzętu i oprogramowania do uruchomienia klienta walidatora Ethereum 2.0? W drugiej części omówię konkretną kombinację sprzętu i oprogramowania, którą wybrałem dla mojego klienta walidatora. Wybory, których dokonasz w zakresie konfiguracji, będą zależeć od zasobów, osobistych upodobań i możliwości technicznych. Zrobię co w mojej mocy, aby podkreślić, w jaki sposób osobiste uprzedzenia i okoliczności wpływały na moje wybory.

        Na koniec, zanim przejdziemy do tego, chciałbym powtórzyć, że te posty są prawie jak wpisy do dziennika z mojego doświadczenia w obstawianiu 32 ETH (aczkolwiek wpisy do dziennika z obszernymi technicznymi aspektami). W związku z tym mogę nieco zmienić swoje podejście w miarę postępu łańcucha beacon. Na przykład pomyślałem, że na pewno będę używać AWS. Jak przeczytasz poniżej, rozważę to ponownie. Będę również bardzo jasny, jeśli chodzi o finansowy element obstawiania. Staking jest sposobem wspierania ekosystemu Ethereum, ale w celu zrównoważonego użytku publicznego powinien być również dostępny i możliwy dla osób, które mają ETH.. 

        Sprzęt sprawdzający przyszłość

        Podstawowe wymagania dotyczące prowadzenia walidatora w dzisiejszych czasach są stosunkowo łatwe do spełnienia. Mara Schmiedt and Collin Meyers ” Przewodnik po walidatorze na Bankless ma dobre zestawienie minimalnych wymagań. Najtrudniejszym aspektem określania wyposażenia walidatora Ethereum 2.0 jest zrównoważenie obecnych potrzeb Beacon Chain Phase 0 z wszelkimi przyszłymi, obecnie nieznanymi wymaganiami w miarę rozwoju. (Nie stanowi to problemu, jeśli czujesz się komfortowo utrzymując ścisłą obserwację swojego walidatora i jesteś w stanie szybko i łatwo reagować na zmiany) 

        Ben Edgington, kierownik projektu Teku i wydawca Eth2.news, dostarczył mi pewnych skrajnych przypadków, w których sieć może wymagać więcej od klienta walidatora. Krótkoterminowo, największym zmartwieniem byłoby coś takiego incydent z serwerem czasu Medalla, w którym błąd i późniejsza poprawka w kliencie Prysm zatrzymały finalizację w sieci testowej (z grubsza mówiąc, sieć nie mogła „produkować bloków”). Ponieważ w sieci nie było ostateczności (brak „potwierdzonych bloków”), weryfikatorzy musieli przechowywać o wiele więcej transakcji w swojej pamięci RAM niż zwykle. 

        W komputerach z 8 GB pamięci RAM – co w normalnych warunkach byłoby więcej niż wystarczające – zaczęły pojawiać się problemy z „brakiem pamięci”, które mogły prowadzić do cięcia. Taki skok, choć niezwykły, nie jest wykluczony w przypadku sieci głównej fazy 0.

        Przyszłe niejasności konfiguracji sieci to połączenie Ethereum 1.0 i 2.0 oraz wprowadzenie shardingu. Nadal nie wiemy, kiedy dojdzie do tych fuzji ani czego będą wymagały. Chciałbym mieć mocny szkielet procesora wchodzący w fazę 0 (4 wirtualne rdzenie, 16 GB pamięci RAM z 100 GB SSD), a następnie skupić się na przyszłych dostosowaniach dotyczących przestrzeni dyskowej (zostawiając tutaj swobodę ruchów). Pamiętaj, że może się to okazać przesadą i pochłonąć nagrody za obstawianie.

        To są „znane niewiadome” przyszłości, omówmy dziś główne punkty decyzyjne dotyczące konfiguracji dla walidatorów.

        Uruchomić lub nie uruchomić klienta Eth1?

        To rytuał przejścia, któremu staram się poddawać naszych studentów bootcampu tak często, jak to możliwe: synchronizowanie klienta Ethereum 1.0. Jest tajemnicą poliszynela, że ​​faktycznie hostowanie „pełnego” węzła Ethereum 1.0 jest aktem miłości, a nie utwardzonym rozwiązaniem dylematu więźnia. „Pełne” należy umieścić w cudzysłowie, ponieważ nawet programiści rdzeni Ethereum mają trudności z uzgodnieniem definicji tego, co właściwie oznacza „pełny węzeł”.

        Jedna rzecz, co do której wszyscy możemy się zgodzić: synchronizacja klienta Ethereum 1.0 zajmuje więcej czasu i pamięci, niż można by sobie wyobrazić. Nasi walidatorzy muszą mieć możliwość wysyłania zapytań do sieciowej bazy danych Ethereum 1.0 (wyjaśnimy dlaczego nieco później). Jeśli chcesz zaoszczędzić miejsce i ból głowy związane z synchronizacją lokalną, możesz użyć punktu końcowego Infura, który jest dostępny bezpłatnie po rejestracji. 

        Mimo że oszczędza to znaczną ilość pamięci masowej i problemów logistycznych, poświęca jednocześnie pewną część decentralizacji dla sieci Eth1 i Eth2. Gdyby Infura upadła, co jest niezwykle rzadkie, ale zdarza się, spowodowałoby to efekt falowania w walidatorach Ethereum 2.0 używających go do ich punktu końcowego Ethereum 1.0. Coś do rozważenia!

        (Żeby było jasne: trudność zsynchronizowania pełnego węzła Ethereum ma związek z naturą stanu świata Ethereum, a nie z podstawowymi programistami Ethereum 1.0, którzy wykonali niesamowitą pracę, radząc sobie z tym niezwykle trudnym problemem.)

        Hosting wirtualny a lokalny

        Następną kwestią dla mnie było hostowanie węzła walidatora lokalnie (w moim domu) lub wirtualnie (na wirtualnym dostawcy usług, takim jak Amazon Web Services (AWS), Digital Ocean itp.). Jak wspomniałem w poprzednim artykule, nie ufam sobie, że uruchomię spójny węzeł walidatora z domu, nawet na starym laptopie, który jest gdzieś przechowywany. Niezdarny i głupkowaty, albo bym go przekopał, albo zapomniał o tym.

        Decyduję się na uruchomienie węzła w AWS, ponieważ to jest to, co znam najlepiej (jednak po przejściu przez cały proces zastanawiam się nad tą decyzją. Omówię to później). Kompromisem jest tutaj ponownie decentralizacja: jeśli AWS ulegnie awarii lub wystąpią jakiekolwiek problemy (tak jak ostatnio), Jestem na ich łasce. Jeśli wystarczająca liczba ludzi obsługuje węzły w AWS, może to wpłynąć na większą sieć Ethereum.

        Ludzie prawdopodobnie sami wybiorą tę opcję. Hosting lokalny to szczególny rodzaj projektu i nie każdy ma czas, zasoby lub wymagane zaangażowanie. Chociaż hosting wirtualny jest siłą centralizującą, decyduję się na to ze względu na jego łatwość użytkowania i (miejmy nadzieję) gwarantowany czas działania. 

        Jeśli chcesz uruchomić węzeł walidatora lokalnie, nadal możesz postępować zgodnie z ogólnym kierunkiem tego samouczka, Doskonała seria samouczków firmy Somer Esat dla różnych klientów lub nawet zsynchronizuj Raspberry Pi Model 4B z 8 GB pamięci RAM z Ethereum na ARM. (Synchronizacja na Raspberry Pi jest nadal bardzo eksperymentalna i ludzie powinni poczekać, aż Ethereum w zespole ARM potwierdzi jego stabilność)

        Wybór klienta Eth2 i unikanie kar

        Innym ważnym wyborem jest klient Ethereum 2.0 spośród istniejących klientów: Latarnia morska, Gwiazda polarna, Chmura, Prysm i Teku. Jestem bardzo stronniczy w stosunku do Teku i nie jestem na tyle bystry, aby dyskutować o drobnych kwestiach klientów. Ten artykuł to przyzwoity przegląd wydajności klienta na Medalla. (Pamiętaj, że Medalla wymagał znacznie więcej od procesorów niż mainnet).

        Proof of Stake zawiera wyraźne czynniki zniechęcające, aby zachęcić do prawidłowego zachowania w sieci. Przyjmują one formę dingingu walidatorów za bycie offline i bardziej dramatycznego ruchu polegającego na cięciu aktorów za podejmowanie złośliwych działań przeciwko sieci, świadomie lub w inny sposób..

        Najczęstszym problemem będzie upewnienie się, że Twój walidator jest dostępny w sieci. Oznacza to upewnienie się, że Twój walidator jest online. Istnieje podejście DevOps do tego problemu – stworzenie systemu monitorowania i ostrzegania, który ostrzega Cię, jeśli Twój walidator przejdzie w tryb offline – którego nie będę tutaj omawiać.

        Ale jest inny sposób, aby stać się niedostępnym dla sieci, a dzieje się tak, jeśli klient zacznie źle się zachowywać z tego czy innego powodu. Po błąd serwera czasu spowodowało spowolnienie sieci na Medalla, deweloperzy rdzeni Eth2 zebrali się, aby się rozwijać „[A] standardowy format przesyłania historii podpisywania klucza umożliwia weryfikatorom łatwe przełączanie się między klientami bez ryzyka podpisywania sprzecznych komunikatów”. Nie wszyscy klienci mają tę ochronę, ale Teku tak. Tutaj możesz przeczytać o korzystaniu z Teku’s Slash Protection (działa domyślnie), w tym o migracji między węzłami Teku lub węzłem innym niż Teku do Teku.

        Jeśli masz problemy z klientem i musisz ponownie uruchomić całą sieć, musisz być świadomy słabej subiektywności. Proof of Work pozwala każdemu wrócić do bloku genezy sieci i bez zaufania zbudować stan sieci od zera. Proof of Stake ma jednak pewien haczyk w tym względzie: jeśli jedna trzecia walidatorów sieci w pewnym momencie kończy pracę, ale nadal podpisuje bloki i poświadczenia, mogą zmienić stan sieci i przesłać te fałszywe dane do węzła synchronizującego sieć, jeśli złośliwi aktorzy złapią węzeł synchronizacyjny, zanim węzeł synchronizujący dotrze do miejsca, w którym weryfikatorzy wycofali swoje fundusze. Możesz przeczytać więcej na ten temat tutaj, ale krótka odpowiedź brzmi: musisz mieć albo „słaby punkt kontrolny subiektywności”, albo zakodowany plik stanu, zasadniczo archiwum sieci. Teku zapewnia flagi startowe dla obu.

        Ostatni problem związany z karą jest najpoważniejszy: cięcie. Slashing występuje, gdy staker działa wbrew regułom sieci. Różni się od kar wynikających z bycia offline. Aktywnie działa przeciwko sieci, przesyłając sprzeczne informacje z walidatora. Jest kilka naprawdę świetnych materiałów, dzięki którym można dowiedzieć się więcej o cięciu i jak mu zapobiegać:

        Głównym wnioskiem jest to, aby nie uruchamiać jednego klucza walidatora na wielu klientach. Najwyraźniej to właśnie spowodowało pierwsze cięcie w historii, które miało miejsce 2 grudnia. Od tamtej pory doszło do wielu cięć! Jeśli przeprowadzasz migrację z jednej instancji do drugiej, czterokrotnie sprawdź, czy nie będziesz mieć dwóch komputerów pracujących z tym samym kluczem:

        Papa Ben mówi, jak to jest. Źródło

        Specyfikacja konfiguracji walidatora AWS + Infura + Teku

        Konfiguracja mojego bloku Genesis:

        System operacyjny: Ubuntu Server 20.04 LTS (HVM) (usługa internetowa Amazon)

        Edytor: Procesor Intel Xeon z serii Platinum 8000, 3,1 GHz. (Usługa internetowa Amazon)

        Pamięć: 4 rdzenie wirtualne, 16 GB RAM (Amazon Web Service)

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

        Klient Ethereum 1.0: Punkt końcowy Infura (bezpłatna warstwa)

        Klient Ethereum 2.0: Teku

        Przeglądając wszystkie powyższe rozważania, nie byłem pewien, jakie jest najlepsze podejście do tworzenia konfiguracji walidatora. Dla siebie chciałbym wybrać maszynę i generalnie nie martwię się o jej wymianę przez co najmniej dwa lata. Pomaga to w całkowitym koszcie walidatora (mogę uzyskać znaczną zniżkę dzięki zablokowaniu się u dostawcy wirtualnego na kilka lat) i nie jestem szczególnie elastyczny w uruchamianiu serwerów. Mam nadzieję, że to przyszłościowe podejście lub „zawyżanie specyfikacji” ułatwi mi życie w ciągu najbliższych dwóch lat..

        Początkowo byłem przekonany, że AWS to najlepsza platforma wirtualna i właśnie z tej usługi będę korzystać w tym i następnym poście. Jednak po przejściu przez cały proces zdałem sobie sprawę, że AWS może być przesadą dla indywidualnego programisty. Prawdziwą siłą AWS wydaje się być jego zdolność do dynamicznego skalowania w górę w celu zaspokojenia popytu, co wiąże się z dodatkowymi kosztami. Ma to sens ekonomiczny w przypadku dużego projektu na poziomie przedsiębiorstwa, ale indywidualnego Ethereum 2.0 obecny wymagania klienta nie wymagają takiego rygoru.

        Zamierzam kontynuować korzystanie z AWS, ale rozważam również możliwość uruchomienia instancji w Digital Ocean, co może być bardziej odpowiednie dla indywidualnego programisty. Więcej na ten temat w późniejszym terminie.

        Skonfiguruj konto Infura

        Decyduję się użyć Infury jako punktu końcowego Ethereum 1.0. Na razie łańcuch beaconów obserwuje umowę depozytu na Ethereum 1.0, aby aktywować nowych stakerów, gdy prawidłowo zdeponują oni 32 ETH i złożyli odpowiednie podpisy BLS.

        W przyszłości łańcuch sygnałów nawigacyjnych rozpocznie testowanie dalszego przetwarzania, zaczynając wykorzystywać informacje o stanie z Ethereum 1.0 do tworzenia równoległych punktów kontrolnych w łańcuchu sygnałów nawigacyjnych.

        Jak wspomnieliśmy powyżej, istnieją dwa główne sposoby uzyskania wglądu do sieci Ethereum 1.0. Jednym z nich jest synchronizacja i aktywne utrzymywanie węzła Ethereum 1.0, który tworzy lokalną bazę danych stanu Ethereum 1.0. Drugim jest skorzystanie z usługi takiej jak Infura, która zapewnia łatwy punkt końcowy Ethereum 1.0, dostępny przez HTTPS lub WebSockets.

        Zarejestruj konto tutaj. Gdy masz już konto, kliknij logo Ethereum po lewej stronie.

        Kliknij „Utwórz nowy projekt” w prawym górnym rogu

        Nazwij swój projekt (mój to „Eth 2 Validator”) i przejdź do „Ustawienia”, upewnij się, że punkty końcowe sieci to „Mainnet” i skopiuj punkt końcowy HTTPS:

        Będziemy go używać później w poleceniu uruchamiania klienta Teku!

        Konfigurowanie instancji AWS

        Konfiguracja instancji EC2 na Amazon jest prosta. Będziemy mieć kilka poprawek tu i tam, aby nasza wirtualna instancja działała dobrze z Teku.

        Utwórz konto AWS (inne niż konto Amazon.com) i zaloguj się do konsoli AWS. Wejdź na stronę EC2, która będzie wyglądać mniej więcej tak:

        Kliknij przycisk „Uruchom instancję”. Zobaczysz następujący ekran:

        System operacyjny

        W tym miejscu wybieramy obraz maszyny (który uważam za system operacyjny), którego chcielibyśmy użyć w naszej wirtualnej instancji. Wybieram Ubuntu Server 20.04, czyli środowisko serwerowe oparte na systemie Linux. Środowisko Ubuntu Server ma kilka kluczowych różnic w optymalizacji w porównaniu ze środowiskiem Ubuntu Desktop. Główną różnicą dla naszych celów jest to, że Ubuntu Server nie ma graficznego interfejsu użytkownika (GUI). Tam, gdzie idziemy, jest tylko wiersz poleceń! Przywraca mi czasy Apple II.

        Po wybraniu naszego systemu operacyjnego wybieramy typ instancji:

        Uważam, że to menu jest dość przytłaczające, więc zamierzam trochę je dla Ciebie rozłożyć. Tutaj wybieramy rdzeń obliczeniowy / moc pamięci RAM / procesor dla naszego komputera. Jest to „surowa” lub „aktywna pamięć” maszyny i oddzielona od pamięci masowej (dysku twardego) urządzenia. Pomyśl o tym jak o silniku naszej wirtualnej instancji, na której będziemy uruchamiać nasz system operacyjny Ubuntu Server. AWS rozdziela je na osobne rodziny instancji oznaczone kombinacją litery / cyfry w skrajnej lewej kolumnie.

        Rodziny instancji mają różne układy sprzętowe, podobnie jak różne silniki samochodowe mają różne konfiguracje tłoków, wtyczek i paliw, aby sprostać różnym wymaganiom. Skoncentrujemy się na dwóch rodzinach instancji „ogólnych obliczeń”, m5 i t3.

        Wybieram instancję m5.xlarge, która zapewnia 4 wirtualne rdzenie obliczeniowe (vCPU) i 16 GB pamięci RAM. Po uruchomieniu sieci głównej Ethereum 2.0 przez około jeden dzień mój komputer nie wykorzystał więcej niż 4% dostępnego procesora wirtualnego. Jak wspomniano w sekcji „Future Proofing” powyżej, wymagania sieci Ethereum 2.0 będą rosły. Ale przez kilka następnych miesięcy, przy braku jakichkolwiek przedłużających się dużych skoków w sieci, najprawdopodobniej byłbym w porządku z instancją m5.large (2 wirtualne rdzenie / vCPU, 8 GB pamięci RAM)

        Bardziej doświadczeni techniczni ludzie niż ja polecili również instancję t3.large jako rozsądną opcję dla Ethereum 2.0. t3.large ma 2 procesory wirtualne i 8 GB pamięci, tak samo jak m5.large, ale rodzina t3 jest zbudowana z myślą o bardziej „zwiększonej” aktywności sieciowej (skoki procesora), a nie rodzina m5 zbudowana z myślą o stałym obciążeniu procesora.

        cennik

        Ostatnią rzeczą, o której należy wspomnieć, zanim przejdziemy do przechowywania, jest cena. AWS jest drogi w porównaniu z innymi opcjami, takimi jak Digital Ocean. Płacisz za procesor (rodzinę instancji) i pamięć masową (dysk twardy) oddzielnie w zależności od tego, z czego korzystasz. Procesor jest opłacany za godzinę. Ponieważ walidatory muszą być online przez 24 godziny, możesz skorzystać z poniższej tabeli cen (od grudnia 2020 r.), Aby dokonać przybliżonych obliczeń: 

        Są to ceny na żądanie. AWS zapewnia coś, co nazywa się Cennik wystąpienia zarezerwowanego, gdzie, jeśli obiecasz mieć wirtualną instancję od roku do trzech lat, możesz uzyskać nawet 50-60% obniżki kosztów w powyższej tabeli cenowej. (Dzięki Jasonowi Chromanowi za tę wskazówkę!)

        Na stronie głównej EC2 kliknij „Reserved Instances” w menu po lewej stronie, pokazane poniżej:

        Kliknij „Kup zarezerwowaną instancję”:

        W wyskakującym menu wpisz szczegóły typu instancji i żądany czas, aby wyświetlić cenę (wybieram m5.xlarge i okres 36-miesięczny):

        Kliknij „Szukaj” i zobacz opcje cenowe:

        Istnieje znaczna obniżka ceny, wydaje mi się, że ponad 50%, ale jestem zamknięty na trzy lata. Po zakupie wystąpienia zarezerwowanego AWS zastosuje je do istniejącego wirtualnego pudełka lub zastosuje je po uruchomieniu. Pamiętaj, że NIE obejmuje to miejsca do przechowywania (dysk twardy). 

        Uwaga: jeszcze tego nie robię, ponieważ nie jestem jeszcze przekonany, że AWS jest najlepszą opcją dla indywidualnego obstawiania od jednego do trzech węzłów walidatora Ethereum 2.0. Prowadzę instancję z ceną na żądanie, aby zobaczyć, jak to działa, zanim zatwierdzę. 

        Przechowywanie

        Wracając do procesu uruchamiania instancji, przechodzimy do karty „Dodaj miejsce”

        Znakomici specjaliści techniczni, z którymi się konsultowałem, zalecali pojemność 100 GB SSD ogólnego przeznaczenia. Pamięć masowa zazwyczaj nie jest wąskim gardłem w przypadku klientów Eth2. Jednak tak jest bez prowadzenie pełnego klienta Eth1. W przypadku pamięci Eth1 konserwatywna szacunkowa wartość wynosiłaby około 1 TB. Pamiętaj, aby wziąć to pod uwagę, jeśli nie używasz Infura.

        Nie znam jednostki w kolumnie IOPS na powyższym obrazku, ale jest to wejście-wyjście dla dysku twardego komunikującego się z procesorem. Jest to klasyczne wąskie gardło dla pełnej synchronizacji węzłów Eth1. Jeśli chcesz zsynchronizować pełnego klienta Eth1 na tym komputerze i masz problemy, może to być miejsce, w którym możesz zajrzeć.

        Porty

        Pomijając „Dodaj tagi”, przejdź do „Konfiguruj grupę zabezpieczeń”. Są to różne otwory utworzone dla różnych rodzajów komunikacji przychodzącej i wychodzącej z instancją.

        AWS automatycznie otwiera tradycyjny port SSH, ponieważ jest to główny sposób interakcji z instancją. Moneta nerkowca i Somer Esat’s doskonałe przewodniki zalecają wyłączenie dostępu do hasła dla SSH, ale zobaczymy, kiedy uruchomimy instancję, która nie jest domyślną opcją dla AWS. Jednak dobrze jest ustawić losowo port SSH na numer z zakresu 1024-65535. Ma to na celu uniemożliwienie złośliwym podmiotom skanowania w sieci standardowego portu SSH. Zobacz, jak ogólnie zabezpieczyć port SSH tutaj a specjalnie dla AWS tutaj.

        Musimy dodać dwie reguły bezpieczeństwa, aby dostosować się do klienta Teku i ma to związek z komunikacją peer-to-peer. Sieci Blockchain są zdecentralizowane w tym sensie, że węzły komunikują się bezpośrednio ze sobą. Zamiast konsultować się z węzłem centralnym, pojedynczy węzeł będzie rozwijał i utrzymywał wiedzę o stanie sieci poprzez „plotkowanie” z wieloma węzłami. Oznacza to, że kiedy jeden klient uzgadnia z innym, wymieniają się informacjami o sieci. Po wykonaniu wystarczającej liczby razy z różnymi węzłami informacje rozprzestrzeniają się w całej sieci. Obecnie mój węzeł Eth2 Validator ma 74 rówieśników, z którymi rozmawia.

        Teku komunikuje się z innymi węzłami na porcie 9000, więc otworzymy to dla UDP i TCP, dwa różne rodzaje protokołów komunikacyjnych. 

        Potem powinno wyglądać mniej więcej tak:

        Klucze SSH i uruchamianie instancji

        Na koniec przejdź do „Review and Launch”, czyli przeglądu dokonanych wyborów. Po zatwierdzeniu pojawi się wyskakujące menu z kluczami SSH. Nie pokazuję swojego, ponieważ zawiera poufne informacje. Mianowicie para kluczy używana do uwierzytelniania i logowania się do wirtualnej instancji poprzez SSH (lokalna linia poleceń). Jeśli nie masz jeszcze pary, AWS wygeneruje ją dla Ciebie. Musisz to pobrać i traktować jak klucz prywatny Ethereum! To jedyny sposób na połączenie się z Twoją instancją, a AWS nie zapisze jej za Ciebie.

        Gdy wszystko będzie kręcone, pojawi się to okno:

        W porządku! To już koniec, przejdźmy do uzyskiwania dostępu i zabezpieczania naszej instancji, a następnie instalowania i uruchamiania Teku!

        Dostęp do instancji

        Głównym sposobem uzyskiwania dostępu do instancji AWS jest SSH, „Protokół kryptograficzny do bezpiecznego świadczenia usług sieciowych w niezabezpieczonej sieci”. Jak wspomniano wcześniej, AWS domyślnie wyłącza uwierzytelnianie hasłem w celu uzyskania dostępu do instancji. Możesz używać tylko pary kluczy wygenerowanej przed uruchomieniem instancji. Para kluczy powinna mieć końcówkę pliku.pem. 

        AWS zapewnia przejrzysty sposób na uzyskanie polecenia SSH. Klikając uruchomioną instancję na głównej stronie EC2, w prawym górnym rogu znajduje się przycisk z napisem „Połącz”:

        Na następnej stronie będzie polecenie SSH specyficzne dla Twojej instancji. Będzie miał następującą strukturę:

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

        Wprowadzenie tego polecenia w terminalu rozpocznie sesję SSH. Za pierwszym razem lokalna maszyna zapyta, czy chcesz zaufać odciskowi palca ECDSA dostarczonemu przez AWS. Ma to na celu zapobieżenie atak man-in-the-middle a jeśli dotyczy, użytkownik może śledzić odcisk cyfrowy swojej instancji te kroki.

        Na terminalu innym niż bieżąca sesja SSH prześlij pliki kluczy walidatora potrzebne do uruchomienia Teku. W poprzednim wpisie na blogu omówiliśmy obstawianie 32 ETH i uzyskiwanie kluczy walidatora dla Ethereum 2.0. Na koniec zostaliśmy z taką strukturą plików:

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

        Musimy przenieść plik validator_key_info do naszej wirtualnej instancji. Secure Copy Protocol (scp) pozwala nam to robić bezpiecznie. Dostosuj ogólne polecenie scp poniżej, używając ścieżki do katalogu powyżej i poprzedniego polecenia SSH:

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

        (Zwróć uwagę na „: ~” na końcu całego polecenia).

        Powinien pojawić się transfer plików. Jeśli wrócisz do sesji SSH i wpiszesz ls, powinieneś zobaczyć przesłany katalog.

        Instalowanie Teku

        Teraz, gdy mamy już potrzebne pliki walidatora, zamierzamy zainstalować Teku. Najpierw musimy zaktualizować istniejące programy i zainstalować wymagane systemy Java:

        Zainstaluj Javę

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

        Podwójne sprawdzenie, czy Java została zainstalowana pomyślnie:

        java -version

        Zainstaluj Binary

        Tutaj znajdziesz najnowsze stabilne wydanie Teku. Skopiuj adres łącza do pliku tar.gz, a następnie z sesji SSH pobierz go. Oto jak wyglądała moja, Twoja wersja najprawdopodobniej będzie inna:

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

        Rozpakuj pobrany plik za pomocą następującego polecenia. Jeśli masz inną wersję, zastąp tę nazwę pliku w przeciwieństwie do teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Ze względu na czystość usuń plik tar.gz.

        Oto jak powinien wyglądać Twój katalog domowy (numer wersji i zawartość Teku mogą się różnić:

        ubuntu / └── teku-20.11.1 / ├── LICENCJA ├── 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

        Utwórz użytkownika innego niż root

        Ten krok jest skopiowany z Somer Esat’s doskonały poradnik Ubuntu / Teku

        Zamierzamy stworzyć użytkownika innego niż root o imieniu teku, który będzie mógł obsługiwać Teku. Wpisz poniżej:

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

        Zamierzamy również utworzyć niestandardowy katalog danych dla Teku, a następnie udostępnić go użytkownikowi teku:

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

        Utwórz usługę systemową

        Ten krok jest zaadaptowany z Somer Esat’s doskonały poradnik Ubuntu / Teku

        Ten krok spowoduje utworzenie usługi, która będzie uruchamiać Teku w tle. Pozwoli to również maszynie na automatyczne ponowne uruchomienie usługi, jeśli z jakiegoś powodu zostanie zatrzymana. Jest to niezbędny krok, aby upewnić się, że nasz walidator działa 24 godziny na dobę, 7 dni w tygodniu.

        Utwórz plik usługi za pomocą edytora tekstu nano:

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

        W tym pliku (który powinien być pusty) zamierzamy umieścić serię poleceń, które systemd będzie wykonywał po uruchomieniu usługi. Oto kod poniżej, musisz zapisać następujące elementy, które zebraliśmy podczas tej podróży:

        • Punkt końcowy HTTP Infura Eth1
        • validator_key_info ścieżka do katalogu z dwoma prawidłowymi plikami związanymi z kluczami
        • Niestandardowa ścieżka danych (lib / var / teku)

        Umieść te wartości w pogrubionym kodzie poniżej, a następnie skopiuj wszystko do edytora tekstu nano:

        [Jednostka] Opis = Węzeł Teku Beacon Wants = network-online.target After = network-online.target [Service] Type = simple User = teku Group = teku Restart = zawsze 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. –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-Locking-enabled = false –data-base-path = / var / lib / teku [Zainstaluj] WantedBy = multi-user.target

        Wpisz polecenie-X, a następnie „Y”, aby zapisać zmiany

        Musimy ponownie uruchomić „systemctl”, aby go zaktualizować:

        sudo systemctl daemon-reload

        Uruchom usługę:

        sudo systemctl start teku

        Sprawdź, czy wszystko się zaczęło:

        sudo systemctl status teku

        Jeśli zauważysz jakieś błędy, uzyskaj więcej informacji, uruchamiając:

        sudo journalctl -f -u teku.service

        Możesz zatrzymać usługę Teku, uruchamiając:

        sudo systemctl stop teku

        Sprawdź stronę rozwiązywania problemów Teku pod kątem typowych błędów lub sprawdź niezgodę Teku, który jest monitorowany przez zespół.

        Gdy poczujesz, że wszystko zostało rozwiązane, włącz usługę, aby ponownie uruchomić, jeśli wyłączy się, uruchamiając:

        sudo systemctl włącz teku

        Masz to! Teraz wszystko powinno się gotować. Podczas inspekcji usługi Teku zobaczysz serię dzienników notujących zdarzenie synchronizacji, to jest twój walidator synchronizujący łańcuch sygnałów nawigacyjnych. Po osiągnięciu szczytu dzienniki te zmienią się i odczytują wydarzenie w automacie, a także zobaczysz wydajność atestacji i propozycje bloków.

        Uruchomić

        Źródło: Beaconcha.in

        1 grudnia o godzinie 12:00 czasu UTC sprawdzono pierwsze bloki Beacon Chain. Nadszedł pierwszy blok Walidator 19026, z enigmatycznym napisem „Pan F. był tutaj”. Dwanaście sekund później pojawił się następny blok, na którym graffiti wskazywało, że może znajdować się walidator Zug, Szwajcaria. Łańcuch Eth2 Beacon rozrastał się równomiernie, blok po bloku co 12 sekund. Potem pojawiła się kolejna przeszkoda: czy wystarczająca liczba walidatorów będzie online, aby sfinalizować pierwszą epokę? Tak! 82,27% walidatorów potwierdziło ważność Epoki 0, przysłowiowego parteru Beacon Chain. Możesz przeczytać więcej o uruchomieniu Beacon Chain i o tym, co dalej, tutaj. 

        Źródło: Beaconcha.in

        Jesteśmy teraz na Epoch 760, co oznacza, że ​​Beacon Chain działa płynnie od prawie tygodnia. 

        Oto ujęcie z mojej perspektywy momentu powstania, przy użyciu konfiguracji opisanej w tym poście:

        W następnej części podsumujemy, jak się sprawy mają. Zamierzam uzyskać dostęp do metryk z Teku, omówić koszty korzystania z AWS i pokrótce omówić stan sieci.

        Bądźcie czujni!

        Zasoby i linki

        Podziękowania dla Jamesa Becka, 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 za wsparcie i pomoc techniczną.

        Biuletyn Ethereum 2.0 Zapisz się do naszego newslettera, aby otrzymywać najnowsze wiadomości o Ethereum, rozwiązania dla przedsiębiorstw, zasoby dla programistów i nie tylko.

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