Follow Us
Facebooktwitteryoutube
YouTube
Promo
banner
Promo
banner

Моето пътуване до превръщането в валидатор на Ethereum 2.0, част 2

блог 1NewsDevelopersEnterpriseBlockchain ExplainedEvent and ConferencesPressБюлетини

Абонирайте се за нашия бюлетин.

Имейл адрес

Ние уважаваме вашата поверителност

HomeBlogDevelopers

Моето пътуване до превръщането в валидатор на Ethereum 2.0, част 2

Кои са нещата, които трябва да имате предвид, когато избирате хардуер и софтуер, за да стартирате клиент за валидатор на Ethereum 2.0? От Coogan Brennan 5 декември 2020 г. Публикувано на 5 декември 2020 г.

Моето пътуване до превръщането в валидатор на Ethereum 2 0 Част 2

Забележка: Все още можете да станете валидатор в мрежата Ethereum 2.0! Ще има време за изчакване, което да бъде активирано като валидатор – от 4 декември 2020 г. времето за изчакване е приблизително 9,9 дни. Вижте стъпките за залагане в Част 1 от тази поредица.

  1. Опровержение
  2. Въведение
  3. Съображения за конфигуриране на валидатор
  1. Бъдещ хардуер за проверка
  2. Да стартирате или да не стартирате клиент Eth1?
  3. Виртуален срещу локален хостинг
  4. Избор на клиенти на Eth2 и избягване на санкции
  • Настройване на екземпляр на AWS
    1. Операционна система
    2. Ценообразуване
    3. Съхранение
    4. Пристанища
    5. SSH ключове и стартиране на инстанция
    6. Инсталиране на Teku
      1. Изисквания
      2. Инсталирайте двоичен файл
      3. Създайте непотребителски потребител
      4. Създайте systemd услуга
      5. Стартиране
      6. Опровержение

        Това е публикация, която пиша като служител на ConsenSys и някой, който планира да заложи на веригата маяци. Първото изявление означава, че приоритизирам продуктите на ConsenSys (продуктите на ConsenSys обикновено са най-добрите в класа за Ethereum, а също така имам достъп до инженерни екипи, които могат да ми помогнат да отговоря на въпроси и да отстранявам проблеми). Последното твърдение означава, че оптимизирам за разходи и лекота на използване: нямам хиляди ETH, за да донеса съществени награди, затова предприемам някои преки пътища. Това са решения, които съм взел, за да направя залагането на Ethereum 2.0 възможно най-просто и достъпно за хората, но идва с компромиси за децентрализация и поверителност. Можете обаче да следвате общите насоки на урока по-долу и да правите различни избори. Всъщност, ако можете да го направите, бих ви насърчил да го направите! 

        И накрая, залагането в Ethereum 2.0 е изключително експериментално и включва дългосрочен ангажимент (отпускам три години). Моля, не участвайте, ако не сте доволни от високо ниво на рискови съпровождащи с нещо, което все още се разработва. Ако не сте сигурни дали трябва да залагате, моля, присъединете се към Раздор между ConsenSys и попитайте в канала # teku-public. 

        Въведение

        В предишната публикация обсъдихме причините за внедряването на Ethereum 2.0 и преминахме през залагането на 32 ETH в Договора за депозит на основната мрежа на Ethereum 1.0. Докоснахме генерирането на ключове и как протича процесът на залагане Launchpad свързва Ethereum 1.0 до 2.0.

        На 23 ноември беше изпълнено минималното количество заложен ETH за стартиране на Ethereum 2.0 – около 524 288. Хората могат да продължат да залагат в договора и броят на валидаторите се е увеличил до над 33 000 от 4 декември.

        Аарон Дейвис на MetaMask споделя мислите си във вътрешния канал за залагане ConsenSys Slack 

        Въпреки че беше изключително вълнуващо да вляза в блока Genesis като валидатор, секунди по-късно имах подобно преживяване с колегата Арън Дейвис във вътрешния ни канал за залагане на ConsenSys: За каква луда задача се бях записал? За щастие имам достъп до невероятно брилянтни и технични хора, достатъчно благотворителни, за да дам на този рубит някои съвети, указания и прозрение за управлението на инфраструктурата за залагане. Надявам се да предам част от този ценен съвет тук на други заинтересовани страни.


        Ето каква ще бъде първата част на тази статия: Какви неща трябва да имате предвид, когато избирате хардуер и софтуер, за да стартирате клиент на валидатор на Ethereum 2.0? Втората част ще разгледа специфичната комбинация хардуер / софтуер, която избрах за моя клиент за валидатор. Изборите, които правите за вашата конфигурация, ще зависят от вашите ресурси, лични наклонности и технически възможности. Ще направя всичко възможно, за да подчертая как личните пристрастия и обстоятелства са информирали моя избор.

        И накрая, преди да се впуснем в него, искам да повторя, че тези публикации са почти като записи в дневника за моя опит, залагайки 32 ETH (макар и записи в списания с обширни технически аспекти). Като такъв, мога да променя малко подхода си с напредването на веригата за маяци. Например си помислих, че определено ще използвам AWS. Както ще прочетете по-долу, сега преразглеждам това. Също така ще бъда много ясен относно финансовия елемент на залагането. Залагането е начин за подпомагане на екосистемата Ethereum, но за устойчива обществена употреба той също трябва да бъде достъпен и възможен за хората, които имат ETH, да го направят. 

        Бъдещ хардуер за проверка

        Основните изисквания за провеждане на валидатор днес са относително лесни за удовлетворяване. Мара Шмид и Колин Майерс Ръководство за валидатор на Bankless има добро изчерпване на минималните изисквания. Най-предизвикателният аспект на определянето на оборудването за валидиране на Ethereum 2.0 е балансирането на текущите нужди на фазата на Beacon Chain 0 с бъдещи неизвестни в момента изисквания, докато развитието продължава. (Това не е притеснително, ако ви е удобно да следите отблизо вашия валидатор и можете бързо и лесно да адресирате промените) 

        Бен Еджингтън, ръководител на проекта в Теку и издател на Eth2.news, ми предостави някои крайни случаи, при които мрежата може да изисква повече от клиента за валидатор. Краткосрочно, най-голямата грижа ще бъде нещо като инцидента със сървъра за време на Medalla, при което грешка и последващо коригиране в клиента Prysm спряха финализирането на тестовата мрежа (грубо казано, мрежата не можеше да „произвежда блокове“). Тъй като в мрежата нямаше окончателност (нямаше „потвърдени блокове“), валидаторите трябваше да държат много повече транзакции в своята RAM от нормалното. 

        Машини с 8 GB RAM – което при нормални обстоятелства би било повече от достатъчно – започнаха да срещат проблеми с „изчерпване на паметта“, което може да доведе до нарязване. Скок като този, макар и необичаен, не е изключен за фаза 0 главна мрежа.

        Бъдещи неясноти в конфигурацията на мрежата са обединяването на Ethereum 1.0 и 2.0 и въвеждането на sharding. Все още не знаем кога ще се случат тези сливания или какво точно ще изискват. Бих искал да имам силен гръбначен стълб на процесора, който влиза във Фаза 0 (4 виртуално ядро, 16 GB RAM със 100 GB SSD) и след това да насоча вниманието си за бъдещи корекции около пространството за съхранение (оставяйки място за раздвижване тук). Моля, обърнете внимание, че това може да се окаже прекалено много и да изяде награди за залагане.

        Това са „известните неизвестни“ на бъдещето, нека обсъдим основните точки за вземане на решения за валидатори днес.

        Да стартирате или да не стартирате клиент Eth1?

        Това е ритуал, който се опитвам да подлагам нашите ученици на bootcamp възможно най-често: синхронизиране на клиент на Ethereum 1.0. Открита тайна е, че всъщност хостването на „пълен“ възел Ethereum 1.0 е по-скоро акт на любов, отколкото втвърдено решение на Prisoner’s Dilemma. „Пълен“ трябва да бъде поставен в кавички, защото дори разработчиците на ядрото на Ethereum имат трудно време да се споразумеят за дефиниция на това, което всъщност означава „пълен възел“.

        Едно нещо, за което всички можем да се съгласим: Отнема повече време и място за синхронизиране на клиент на Ethereum 1.0, отколкото бихте си представили. Нашите валидатори трябва да имат начин за заявка на мрежовата база данни Ethereum 1.0 (ще разберем защо малко по-късно). Ако искате да спестите място и главоболие при синхронизиране локално, можете да използвате крайна точка на Infura, която е достъпна безплатно с регистрация. 

        Въпреки че това спестява значително съхранение и логистична загриженост, то жертва известна степен на децентрализация за мрежите Eth1 и Eth2 едновременно. Ако Инфура трябваше да слезе, което е изключително рядко, но се среща, което би предизвикало ефект на пулсации в валидаторите на Ethereum 2.0, използвайки го за своята крайна точка Ethereum 1.0. Нещо за разглеждане!

        (Само за да бъде ясно: трудността при синхронизирането на пълен възел на Ethereum е свързана с естеството на световното състояние на Ethereum, а не с основните разработчици на Ethereum 1.0, които са свършили невероятна работа, занимавайки се с този изключително труден проблем.)

        Виртуален срещу локален хостинг

        Следващото съображение за мен беше хостването на валидационен възел локално (в моя дом) или виртуално (на виртуален доставчик на услуги като Amazon Web Services (AWS), Digital Ocean и др.). Както споменах в предишното парче, не си вярвам да стартирам последователен валидационен възел от вкъщи, дори на стар лаптоп, съхраняван някъде. Неудобен и шантав, щях да го ритна или да забравя за него.

        Избирам да стартирам своя възел на AWS, защото това е, което най-добре ми е познато (След като преминах през целия този процес, обаче, второ предполагам това решение. Ще обсъдя това по-късно). Компромисът тук е отново децентрализация: Ако AWS падне или има някакви проблеми (както го направи наскоро), Аз съм в тяхната милост. Ако достатъчно хора изпълняват възли на AWS, това може да повлияе на по-голямата мрежа Ethereum.

        Хората вероятно ще се самоизбират за този. Местният хостинг е специален вид проект и не всеки има необходимото време, ресурси или ангажимент. Въпреки че виртуалният хостинг е централизираща сила, аз решавам да го използвам поради неговата лекота на използване и (надявам се) гарантирано ъптайм. 

        Ако искате да стартирате локализиращ възел локално, пак можете да следвате общата насока на този урок, Отличната поредица от уроци на Somer Esat с различни клиенти или дори да синхронизирате Raspberry Pi Model 4B с 8 GB RAM с Ethereum на ARM. (Синхронизирането на Raspberry Pi все още е много експериментално и хората трябва да изчакат, докато екипът на Ethereum в ARM потвърди своята стабилност)

        Избор на клиенти на Eth2 и избягване на санкции

        Друг основен избор е клиентът Ethereum 2.0 сред съществуващите клиенти: фар, Лодестар, Нимбус, Призма и Теку. Аз съм силно пристрастен към Теку и не съм достатъчно разумен, за да обсъждам фините точки на клиентите. тази статия е достоен преглед на представянето на клиентите на Medalla. (Имайте предвид, че Medalla изискваше много повече от процесорите, отколкото основната мрежа.)

        Proof of Stake включва явни пречки за насърчаване на правилното поведение в мрежата. Те са под формата на измервателни валидатори за офлайн и по-драматичния ход на нарязване на актьори за предприемане на злонамерени действия срещу мрежата, съзнателно или по друг начин.

        Най-често срещаният проблем ще бъде увереността, че вашият валидатор е достъпен за мрежата. Това означава да се уверите, че вашият валидатор е онлайн. Има подход DevOps към този проблем – създаване на система за мониторинг и предупреждение, която да ви предупреждава, ако валидаторът ви излезе офлайн – който няма да разглеждам тук.

        Но има и друг начин да бъдете недостъпни за мрежата и това е, ако вашият клиент започне да се държи лошо по една или друга причина. След грешката на сървъра за време предизвика забавяне на мрежата на Medalla, основните разработчици на Eth2 се събраха, за да се развият „[A] стандартен формат за прехвърляне на историята на подписване на ключ позволява на валидаторите лесно да превключват между клиенти, без риск от подписване на конфликтни съобщения.“ Не всички клиенти имат тази защита, но Teku го има. Тук можете да прочетете за използването на Teku’s Slash Protection (работи по подразбиране), включително мигриране между Teku възли или не-Teku към Teku възел.

        Ако имате проблеми с клиента си и трябва да рестартирате цялата мрежа, трябва да сте наясно със слабата субективност. Доказателството за работа позволява на всеки да се върне към генезисния блок на мрежата и без доверие да изгради състоянието на мрежата от нулата. Доказателството за залог обаче има уловка в това отношение: Ако една трета от валидаторите на мрежата на дадена точка излизане все още продължава да подписва блокове и атестация, те могат да променят състоянието на мрежата и да подават тези фалшиви данни към възел, който се синхронизира с мрежа, ако злонамерените участници хванат синхронизиращия възел, преди синхронизиращият възел да достигне мястото, където валидаторите са изтеглили средствата си. Можете да прочетете повече за това тук, но краткият отговор е, че трябва да имате или „слаба контролна точка за субективност“, или кодиран държавен файл, по същество архив на мрежата. Teku предоставя флагчета за стартиране и за двете.

        Последното притеснение за наказанието е най-сериозното: Нарязване. Нарязването се случва, когато залагащ работи срещу правилата на мрежата. Различно е от това да бъдете наказани от това да сте офлайн. Той работи активно срещу мрежата, като изпраща противоречива информация за валидатор. Има някои наистина страхотни материали, за да научите повече за нарязването и как да го предотвратите:

        Основното извеждане е да не пускате един ключ за валидация на множество клиенти. Очевидно това е причината за първото съкращаващо събитие някога, което се случи на 2 декември. Оттогава има редица нарязвания! Ако мигрирате от един екземпляр в друг, четворна проверка, че няма да имате две машини, работещи от един и същ ключ:

        Папа Бен го разказва така, както е. Източник

        Спецификации на конфигурацията на AWS + Infura + Teku Validator

        Настройка на блока ми Genesis:

        Операционна система: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

        Процесор: Процесор Intel Xeon Platinum 8000, 3.1 GHz. (Amazon Web Service)

        Памет: 4 виртуални ядра, 16 GB RAM (Amazon Web Service)

        Съхранение: 100 GB SSD, 300/3000 IOPS (Amazon Web Service)

        Клиент на Ethereum 1.0: Крайна точка на Infura (безплатно ниво)

        Клиент на Ethereum 2.0: Теку

        Разглеждайки всички горепосочени съображения, не бях сигурен в най-добрия подход за изграждане на настройка на валидатор. За себе си бих искал да избера машина и като цяло не се притеснявам да я сменя поне две години. Това помага за общите разходи за валидатор (мога да получа значителна отстъпка от заключването с виртуален доставчик за няколко години) и не съм особено пъргав с въртящите се сървъри. Този подход за бъдеща проверка или „свръхспецификация“ се надявам да направи живота ми през следващите две години малко по-лесен.

        Първоначално бях убеден, че AWS е най-добрата виртуална платформа и това е услугата, която ще използвам за тази и следващата публикация. След като преминах през целия процес, разбрах, че AWS може да е прекалено голям за отделния разработчик. Реалната сила на AWS изглежда е способността му да се мащабира динамично, за да отговори на търсенето, което е с премия. Това има икономически смисъл за мащабен проект на ниво предприятие, но индивидуален Ethereum 2.0 текущ изискванията на клиента не изискват такава строгост.

        Ще продължа с AWS, но също така забавлявам възможността да стартирам екземпляр на Digital Ocean, което може да е по-подходящо за отделен разработчик. Повече за това на по-късна дата.

        Настройване на акаунт в Infura

        Избирам да използвам Infura като моя крайна точка Ethereum 1.0. Засега веригата маяци наблюдава Договора за депозит на Ethereum 1.0, за да активира нови залагащи, когато те депозираха правилно 32 ETH и подадоха подходящи BLS подписи.

        В бъдеще веригата за маяци ще започне да тества по-нататъшна обработка, като започне да използва информация за състоянието от Ethereum 1.0 за създаване на паралелни контролни точки на веригата за маяци.

        Както споменахме по-горе, има два основни начина да видим мрежата Ethereum 1.0. Единият е да синхронизирате и поддържате активно възел Ethereum 1.0, който създава локална база данни за състоянието на Ethereum 1.0. Другото е да използвате услуга като Infura, която предоставя лесна крайна точка на Ethereum 1.0, достъпна чрез HTTPS или WebSockets.

        Подпишете се за акаунт тук. След като имате акаунт, щракнете върху логото на Ethereum отляво.

        Щракнете върху „Създаване на нов проект“ в горния десен ъгъл

        Дайте име на проекта си (моят е „Eth 2 Validator“) и отидете в „Настройки“, уверете се, че крайните точки на вашата мрежа са „Mainnet“ и копирайте крайната точка на HTTPS:

        Ще използваме това по-късно за нашата команда за стартиране на клиента Teku!

        Настройване на екземпляр на AWS

        Настройването на екземпляр EC2 на Amazon е директно. Ще имаме няколко ощипвания тук и там, за да помогнем на нашия виртуален екземпляр да играе добре с Teku.

        Създайте акаунт в AWS (различен от акаунт на Amazon.com) и влезте в AWS Console. Отидете до страницата EC2, която ще изглежда по следния начин:

        Щракнете върху бутона „Стартиране на екземпляр“. След това ще видите следния екран:

        Операционна система

        Тук избираме какъв машинен образ (който мисля като операционна система) бихме искали да използваме на нашия виртуален екземпляр. Избирам Ubuntu Server 20.04, който е Linux-базирана сървърна среда. Средата на Ubuntu Server има няколко ключови разлики в оптимизацията от средата на Ubuntu Desktop. Основната разлика за нашите цели е, че Ubuntu Server няма графичен потребителски интерфейс (GUI). Където отиваме, има само команден ред! Връща ме към дните на Apple II.

        След като изберем нашата операционна система, след това избираме типа на своя екземпляр:

        Намирам това меню за поразително, така че ще го разбия малко за вас. Тук избираме изчислителното ядро ​​/ мощност на RAM / процесор за нашата машина. Това е „суровата“ или „активна памет“ на машината и отделно от хранилището (твърдия диск) на устройство. Помислете за това като за двигател на нашия виртуален екземпляр, на който ще стартираме нашата операционна система Ubuntu Server. AWS ги разделя на отделни семейства на екземпляри, обозначени с комбинацията букви / числа в крайната лява колона.

        Семействата екземпляри имат различни хардуерни механизми, точно както различните двигатели на автомобилите имат различни конфигурации на бутала, свещи и горива, за да отговорят на различни изисквания. Ще се съсредоточим върху две от техните семейства „общи изчисления“, m5 и t3.

        Избирам екземпляра m5.xlarge, който предоставя 4 виртуални изчислителни ядра (vCPU) и 16 GB RAM. След като стартирах основната мрежа на Ethereum 2.0 за около ден, машината ми не използва повече от 4% от наличния vCPU. Както бе споменато в раздела „Проверка на бъдещето“ по-горе, изискванията на мрежата Ethereum 2.0 ще нарастват само. Но през следващите няколко месеца, при липса на продължителни големи мрежови скокове, най-вероятно ще се оправя с m5.large екземпляр (2 виртуални ядра / vCPU, 8 GB RAM)

        Техници, по-разбиращи от мен, също препоръчват екземпляра t3.large като разумна опция за Ethereum 2.0. t3.large има 2 vCPU и 8 GB памет, същите като m5.large, но семейството t3 е създадено за по-„разглобяема“ мрежова активност (скокове в процесора), отколкото семейството m5, създадено за постоянни натоварвания на процесора.

        Ценообразуване

        Последното нещо, което трябва да споменем, преди да преминем към съхранението, е цената. AWS е скъпо в сравнение с други опции като Digital Ocean. Вие плащате за процесора (вашето семейство екземпляри) и хранилището (вашия твърд диск) отделно в зависимост от това, което използвате. CPU се заплаща на час. Тъй като валидаторите трябва да са онлайн 24 часа, можете да използвате таблицата с цените по-долу (от декември 2020 г.), за да направите някои груби изчисления: 

        Това са цени при поискване. AWS предоставя нещо, наречено Цени на резервиран екземпляр, където, ако обещаете да имате виртуален екземпляр от година до три години, можете да получите до 50-60% намаление на разходите по горната таблица с цени. (Благодаря на Джейсън Кроман за този съвет!)

        От началната страница на EC2 щракнете върху „Резервирани екземпляри“ в лявото меню, показано по-долу:

        Кликнете върху „Закупен резервиран екземпляр“:

        В изскачащото меню въведете подробности за типа на екземпляра и желаното време, за да видите ценообразуването (избирам m5.xlarge и 36-месечен срок):

        Щракнете върху „Търсене“ и вижте ценовите опции:

        Има значителна ценова отстъпка, вярвам над 50%, но съм заключен от три години. След като закупите резервирания екземпляр, AWS след това го прилага към съществуваща виртуална кутия или ще го приложи, след като бъде стартиран. Не забравяйте, че това НЕ включва място за съхранение (твърд диск). 

        Забележка: Все още не правя това, тъй като все още не съм убеден, че AWS е най-добрият вариант за индивидуално залагане на един до три Ethereum 2.0 възела за валидация. Изпълнявам екземпляр с ценообразуване при поискване, за да видя как върви, преди да се ангажирам. 

        Съхранение

        Връщайки се към нашия процес на стартиране на екземпляр, ние преминаваме към раздела „Добавяне на хранилище“

        Блестящите технически хора, с които се консултирах, препоръчаха 100 GB SSD за общо предназначение. Съхранението обикновено не е пречка за клиентите на Eth2. Това обаче е така без работещ пълен клиент на Eth1. За съхранение на Eth1 консервативната предположение би била около 1TB. Не забравяйте да отчетете това, ако не използвате Infura.

        Не познавам устройството в колоната IOPS на изображението по-горе, но това е входно-изходният сигнал за твърдия диск, комуникиращ с процесора. Това е класическо тесно място за пълно синхронизиране на възел Eth1. Ако търсите да синхронизирате пълен клиент на Eth1 на тази машина и имате проблеми, това може да е място за търсене.

        Пристанища

        Прескачайки „Добавяне на маркери“, преминете към „Конфигуриране на групата за сигурност“. Това са различните отвори, създадени за различни видове входяща и изходяща комуникация с екземпляра.

        AWS автоматично отваря традиционния SSH порт, тъй като това е основният начин за взаимодействие с екземпляра. Монета кашу и Somer Esat’s отличните ръководства препоръчват деактивиране на достъпа до парола за SSH, но ще видим, когато стартираме екземпляра, който не е опцията по подразбиране за AWS. Добре е обаче да рандомизирате вашия SSH порт до номер между 1024-65535. Това е за предотвратяване на злонамерени участници от мрежово сканиране на стандартния SSH порт. Вижте как да защитите вашия SSH порт като цяло тук и по-специално за AWS тук.

        Трябва да добавим две правила за сигурност, за да приспособим клиента Teku и това е свързано с комуникация между връстници. Блочните вериги са децентрализирани в смисъл, че възлите говорят директно помежду си. Вместо да се консултира с централен възел, отделен възел ще разработи и поддържа разбиране за състоянието на мрежата, като „клюкарства“ с много възли. Това означава, че когато един клиент се ръкува с друг, те си разменят информация за мрежата. Извършено достатъчно пъти с различни възли, информацията се разпространява в цялата мрежа. Понастоящем моят възел за проверка на Eth2 има 74 връстници, с които разговаря.

        Teku комуникира с други възли на порта 9000, така че ще го отворим за UDP и TCP, два различни вида комуникационни протоколи. 

        След това трябва да изглежда по следния начин:

        SSH ключове и стартиране на инстанция

        Накрая отидете на „Преглед и стартиране“, преглед на направените избори. След като бъде одобрен, ще има изскачащо меню за SSH ключовете. Не показвам моята, защото тя съдържа чувствителна информация. А именно, двойката ключове, използвана за удостоверяване и влизане във виртуалния екземпляр чрез SSH (локален команден ред). Ако все още нямате чифт, AWS ще генерира такъв за вас. Трябва да изтеглите това и да го третирате като частен ключ на Ethereum! Това е единственият начин да се свържете с вашия екземпляр и AWS няма да го запази за вас.

        След като всичко е хънки, ще се появи този прозорец:

        Добре! Това е готово, нека да преминем към достъп и защита на нашия екземпляр, след което да инсталираме и стартираме Teku!

        Достъп до инстанция

        Основният начин за достъп до екземпляра на AWS е чрез SSH, „Криптографски протокол за безопасна работа на мрежови услуги през незащитена мрежа.“ Както бе споменато по-рано, AWS по подразбиране деактивира удостоверяването с парола за достъп до екземпляра. Можете да използвате само двойката ключове, генерирана преди стартирането на екземпляра. Ключовата пара трябва да има a.pem файл, завършващ. 

        AWS предоставя чист начин да получите вашата SSH команда. Кликвайки върху работещия екземпляр от главната страница на EC2, в горната дясна ръка има бутон, който казва „свързване“:

        На следващата страница ще има SSH команда, специфична за вашия екземпляр. Тя ще бъде структурирана по следния начин:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [имейл защитен]_IDENTIFIER.compute-ZONE.amazonaws.com

        Въвеждането на тази команда в терминал ще започне SSH сесията. За първи път локалната машина ще попита дали искате да се доверите на ECDSA пръстовия отпечатък, предоставен от AWS. Това е, за да се предотврати a атака човек в средата и, ако е засегнат, потребителят може да получи следния пръстов отпечатък на своя екземпляр тези стъпки.

        В терминал, отделен от текущата SSH сесия, прехвърлете валидационните ключови файлове, необходими за стартиране на Teku. В предишната публикация в блога преминахме през залагането на 32 ETH и получаването на валидационни ключове за Ethereum 2.0. Накрая ни остана тази файлова структура:

        eth2deposit-cli / └── ключ за проверка на валидността / ├── KEYSTORE-M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Трябва да прехвърлим файла validator_key_info към нашия виртуален екземпляр. Протоколът за защитено копиране (scp) ни позволява да направим това сигурно. Адаптирайте общата команда scp по-долу, като използвате пътя към директорията по-горе и предишната команда SSH:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [имейл защитен]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Обърнете внимание на „: ~“ в края на цялата команда.)

        Трябва да видите прехвърляне на файл. Ако се върнете обратно към вашата SSH сесия и напишете ls, трябва да видите прехвърлената директория.

        Инсталиране на Teku

        Сега, след като разполагаме с валидаторните файлове, от които се нуждаем, ще инсталираме Teku. Първо, трябва да актуализираме съществуващите програми и да инсталираме необходимите Java системи:

        Инсталирайте Java

        sudo apt актуализация && sudo apt инсталирайте default-jre && sudo apt install default-jdk

        Двойната проверка на инсталираната Java беше успешна с:

        java -версия

        Инсталирайте двоичен файл

        Намерете най-новата стабилна версия на Teku тук. Копирайте адреса на връзката във файла tar.gz, след което го изтеглете от вашата SSH сесия. Ето как изглеждаше моята, вашата версия най-вероятно ще бъде различна:

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

        Декомпресирайте изтегления файл със следната команда. Ако имате различна версия, добавете това име на файл за разлика от teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        За чистота премахнете файла tar.gz.

        След всички тези стъпки ето как трябва да изглежда вашата домашна директория (номерът и съдържанието на версията на Teku може да са различни:

        ubuntu / └── teku-20.11.1 / ├── ЛИЦЕНЗА ├── bin / ├── lib / ├── лиценз-зависимост.html ├── teku.autocomplete.sh └── validator_key_info / ├── КЛЮЧ -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Създайте потребител без root

        Тази стъпка е копирана от Somer Esat’s отличен урок за Ubuntu / Teku

        Ще създадем потребител без root, наречен teku, който може да управлява Teku. Въведете следното по-долу:

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

        Ще създадем и персонализирана директория с данни за Teku, след което ще дадем на текущия потребител достъп до нея:

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

        Създайте systemd услуга

        Тази стъпка е адаптирана от Somer Esat’s отличен урок за Ubuntu / Teku

        Тази стъпка ще направи услуга, която ще изпълнява Teku във фонов режим. Това също ще позволи на машината автоматично да рестартира услугата, ако спре по някаква причина. Това е необходима стъпка, за да сте сигурни, че нашият валидатор работи 24-7.

        Създайте файла на услугата, като използвате нано текстов редактор:

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

        В този файл (който трябва да е празен) ще въведем поредица от команди, които systemd да изпълнява, когато стартираме услугата. Ето кода по-долу, ще трябва да добавите в следните елементи, които сме събрали по време на това пътуване:

        • Крайна точка на Infura Eth1 HTTP
        • път на директория validator_key_info с два валидни файла, свързани с ключ
        • Персонализиран път на данни (lib / var / teku)

        Поставете тези стойности в удебеления код по-долу, след което копирайте всичко в нано текстовия редактор:

        [Единица] Описание = 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/KEYABCD56.M89 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –data-base-path = / var / lib / teku [Инсталиране] WantedBy = multi-user.target

        Въведете command-X, след това въведете „Y“, за да запазите промените си

        Трябва да рестартираме “systemctl”, за да го актуализираме:

        sudo systemctl daemon-reload

        Стартирайте услугата:

        sudo systemctl старт teku

        Проверете дали всичко започва добре:

        sudo systemctl статус теку

        Ако видите грешки, получете повече подробности, като изпълните:

        sudo journalctl -f -u teku.service

        Можете да спрете услугата Teku, като изпълните:

        sudo systemctl стоп теку

        Проверете страницата за отстраняване на неизправности на Teku за често срещани грешки или вижте раздора Теку, което се следи от екипа.

        След като почувствате, че нещата са изгладени, разрешете услугата да се рестартира, ако се изключи чрез стартиране:

        sudo systemctl разреши teku

        Ето го! Нещата трябва да се готвят точно сега. Когато инспектирате услугата Teku, ще видите серия от дневници, отбелязващи Събитие за синхронизация, това е вашият валидатор, който синхронизира веригата на маяка. След като достигне главата, тези регистрационни файлове ще се променят, за да прочетат Slot Event, а също така ще видите ефективността на атестацията си и ще блокирате предложения.

        Стартиране

        Източник: Beaconcha.in

        На 1 декември в 12:00 UTC, валидираха първите блокове на Beacon Chain. Първият блок дойде от Валидатор 19026, със загадъчните графити: „Господин Ф беше тук.“ Дванадесет секунди по-късно дойде следващият блок, графити, показващи, че валидаторът може да се намира в Цуг, Швейцария. Веригата Eth2 Beacon нараства стабилно, блок по блок на всеки 12 секунди. След това дойде следващото препятствие: ще има ли достатъчно валидатори онлайн, за да финализира първата Епоха? Да! 82,27% от валидаторите потвърдиха валидността на Epoch 0, пословичния партер на Beacon Chain. Можете да прочетете повече за пускането на Beacon Chain и какво следва, тук. 

        Източник: Beaconcha.in

        Вече сме на Epoch 760, което означава, че Beacon Chain работи гладко от почти седмица. 

        Ето снимка от моята гледна точка на момента на генезиса, използвайки настройката, описана в тази публикация:

        На следващата вноска ще направим обобщение на това как вървят нещата. Ще вляза в метриките от Teku, ще обсъдя цената за пускане на AWS и ще обсъдя накратко състоянието на мрежата.

        Останете на линия!

        Ресурси и връзки

        Благодаря на Джеймс Бек, Мередит Бакстър, Джейсън Кроман, Арън Дейвис, Чаминда Дивитотавела, Бен Еджингтън, Тъмният шут, Сомер Есат, Джоузеф Любин, Колин Майерс, Ник Нелсън, Мара Шмид, Адриан Сътън и Алекс Тудораче за подкрепата и техническата помощ.

        Ethereum 2.0 Newsletter Абонирайте се за нашия бюлетин за най-новите новини за Ethereum, корпоративни решения, ресурси за разработчици и други.

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