Мой путь к тому, чтобы стать валидатором на Ethereum 2.0, часть 2
НовостиДля разработчиковПредприятиеБлокчейн РазъяснениеМероприятия и конференцииПрессаИнформационные бюллетени
Подписывайтесь на нашу новостную рассылку.
Адрес электронной почты
Мы уважаем вашу конфиденциальность
ГлавнаяБлогДля разработчиков
Мой путь к тому, чтобы стать валидатором на Ethereum 2.0, часть 2
Что следует учитывать при выборе оборудования и программного обеспечения для запуска клиента-валидатора Ethereum 2.0? Автор: Куган Бреннан, 5 декабря 2020 г.Опубликовано 5 декабря 2020 г.
Примечание: вы все еще можете стать валидатором в сети Ethereum 2.0! Будет время ожидания для активации в качестве валидатора – по состоянию на 4 декабря 2020 года время ожидания составляет примерно 9.9 дней. См. Пошаговые инструкции по размещению ставок в части 1 этой серии статей..
- Отказ от ответственности
- Вступление
- Рекомендации по настройке валидатора
- Аппаратное обеспечение будущего
- Запускать или не запускать клиент Eth1?
- Виртуальный и локальный хостинг
- Выбор клиента Eth2 и избежание штрафов
Отказ от ответственности
Это сообщение, которое я пишу как сотрудник ConsenSys и кто-то планирует сделать ставку на цепочку маяков. Первое утверждение означает, что я отдаю приоритет продуктам ConsenSys (продукты ConsenSys обычно являются лучшими в своем классе для Ethereum, и у меня также есть доступ к командам инженеров, которые могут помочь мне ответить на вопросы и устранить неполадки). Последнее утверждение означает, что я оптимизирую расходы и простоту использования: у меня нет тысяч ETH для получения существенного вознаграждения, поэтому я выбираю несколько сокращений. Это решения, которые я принял, чтобы сделать ставку на Ethereum 2.0 как можно более простым и доступным для отдельных лиц, но с компромиссом в отношении децентрализации и конфиденциальности. Однако вы можете следовать общим указаниям приведенного ниже урока и делать другой выбор. На самом деле, если вы можете это сделать, я бы посоветовал вам!
Наконец, стейкинг в Ethereum 2.0 носит экспериментальный характер и предполагает долгосрочные обязательства (я выделяю три года). Пожалуйста, не участвуйте, если вас не устраивает сопутствующий высокий уровень риска, и что-то еще находится в разработке. Если вы не уверены, стоит ли делать ставки, присоединяйтесь к ConsenSys раздор и спросите в канале # teku-public.
Вступление
В предыдущем посте мы обсудили причины развертывания Ethereum 2.0 и рассмотрели размещение 32 ETH в депозитном контракте основной сети Ethereum 1.0. Мы коснулись генерации ключей и процесса стейкинга. Панель запуска связывает Ethereum 1.0 с 2.0.
23 ноября была достигнута минимальная ставка ETH для запуска Ethereum 2.0 – около 524 288 евро. Люди могут продолжать делать ставки в контракте, и по состоянию на 4 декабря количество валидаторов увеличилось до 33000..
Аарон Дэвис из MetaMask делится своими мыслями на внутреннем канале стекинга ConsenSys Slack
Хотя было чрезвычайно интересно попасть в блок Genesis в качестве валидатора, через несколько секунд у меня был аналогичный опыт с моим коллегой Аароном Дэвисом на нашем внутреннем канале ставок ConsenSys: для какой безумной задачи я подписался? К счастью, у меня есть доступ к невероятно блестящим и техническим людям, достаточно милосердным, чтобы дать этому рубу несколько советов, указателей и понимание того, как работает инфраструктура стекинга. Я надеюсь передать часть этого ценного совета любым другим заинтересованным сторонам..
Вот что будет в первой части этой статьи: что вы должны учитывать при выборе оборудования и программного обеспечения для запуска клиента-валидатора Ethereum 2.0? Во второй части будет рассмотрена конкретная комбинация аппаратного и программного обеспечения, которую я выбрал для своего клиента-валидатора. Выбор, который вы сделаете для своей конфигурации, будет зависеть от ваших ресурсов, личных предпочтений и технических возможностей. Я сделаю все возможное, чтобы подчеркнуть, как личные предубеждения и обстоятельства повлияли на мой выбор..
Наконец, прежде чем мы перейдем к этому, я хочу повторить, что эти сообщения почти похожи на записи в журнале из-за моего опыта, связанного с ставкой 32 ETH (хотя и журнальные записи с обширными техническими аспектами). Таким образом, я могу немного изменить свой подход по мере развития цепочки маяков. Например, я подумал, что определенно буду использовать AWS. Как вы прочитаете ниже, я сейчас пересматриваю это. Я также собираюсь очень четко указать на финансовую составляющую стекинга. Ставки – это способ поддержки экосистемы Ethereum, но для устойчивого общественного использования он также должен быть доступен и возможен для людей, у которых есть ETH, чтобы делать это..
Аппаратное обеспечение будущего
Основные требования для запуска валидатора сегодня относительно легко удовлетворить. Мара Шмидт и Коллин Мейерс Руководство по валидатору on Bankless имеет хорошее изложение минимальных требований. Наиболее сложным аспектом определения оборудования валидатора Ethereum 2.0 является балансирование текущих потребностей фазы 0 Beacon Chain с любыми будущими, пока неизвестными требованиями, по мере продолжения разработки. (Это не проблема, если вам удобно внимательно следить за своим валидатором и вы можете быстро и легко реагировать на изменения)
Бен Эджингтон, менеджер проектов Teku и издатель Eth2.news, предоставил мне некоторые крайние случаи, когда сеть может потребовать больше от клиента валидатора. В краткосрочной перспективе самой большой проблемой будет что-то вроде инцидент с сервером времени Medalla, в котором ошибка и последующее исправление в клиенте Prysm остановили финализацию в тестовой сети (грубо говоря, сеть не могла «создавать блоки»). Поскольку в сети не было завершенности (никаких «подтвержденных блоков»), валидаторам приходилось удерживать в своей оперативной памяти намного больше транзакций, чем обычно..
Машины с 8 ГБ ОЗУ – чего было бы более чем достаточно при нормальных обстоятельствах – начали сталкиваться с проблемами «нехватки памяти», которые могли привести к сокращению. Такой всплеск, хотя и необычный, не исключен для основной сети фазы 0..
Будущие неоднозначности конфигурации сети – это слияние Ethereum 1.0 и 2.0 и введение шардинга. Мы до сих пор не знаем, когда произойдет это слияние и что именно им потребуется. Я хотел бы, чтобы в Фазу 0 была сильная магистраль ЦП (4 виртуальных ядра, 16 ГБ ОЗУ и 100 ГБ SSD), а затем сосредоточить свое внимание на будущих корректировках, касающихся пространства для хранения (оставляя здесь место для маневра). Обратите внимание, что это может оказаться излишним и съесть вознаграждение за стекинг..
Это «известные неизвестные» будущего, давайте сегодня обсудим основные моменты принятия решения о конфигурации для валидаторов..
Запускать или не запускать клиент Eth1?
Это обряд посвящения, которому я стараюсь как можно чаще подвергать наших студентов: синхронизация клиента Ethereum 1.0. Ни для кого не секрет, что на самом деле размещение «полной» ноды Ethereum 1.0 – это скорее акт любви, чем жесткое решение «дилеммы заключенного». «Полный» необходимо заключить в кавычки, потому что даже разработчикам ядра 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 ГБ ОЗУ с Ethereum на ARM. (Синхронизация на Raspberry Pi все еще является экспериментальной, и людям следует подождать, пока команда Ethereum в ARM не подтвердит ее стабильность)
Выбор клиента Eth2 и избежание штрафов
Еще один важный выбор – клиент Ethereum 2.0 среди существующих клиентов: Маяк, Lodestar, Нимбус, Prysm и Теку. Я сильно предвзято отношусь к Teku и недостаточно сообразителен, чтобы обсуждать тонкости клиентов.. Эта статья – достойный обзор производительности клиентов в Medalla. (Имейте в виду, что Medalla требовала от процессоров гораздо большего, чем основная сеть.)
Proof of Stake содержит явные сдерживающие факторы для поощрения правильного поведения в сети. Они принимают форму оскорбления валидаторов за то, что они не работают, и более драматических действий по отрубанию акторов за злонамеренные действия против сети, сознательно или иным образом..
Наиболее частая проблема – убедиться, что ваш валидатор доступен в сети. Это означает, что ваш валидатор должен быть в сети. Существует подход DevOps к этой проблеме – создание системы мониторинга и предупреждений, чтобы предупредить вас, если ваш валидатор отключится, – я не буду здесь рассматривать.
Но есть еще один способ быть недоступным для сети, и это если ваш клиент начинает плохо себя вести по той или иной причине. После ошибка сервера времени вызвало замедление работы сети на Medalla, разработчики ядра Eth2 объединились для разработки «[A] стандартный формат для передачи истории подписи ключа позволяет валидаторам легко переключаться между клиентами без риска подписания конфликтующих сообщений». Не у всех клиентов есть эта защита, но у Teku есть. Здесь вы можете прочитать об использовании Teku’s Slash Protection (запускается по умолчанию), включая миграцию между узлами Teku или узлами, не относящимися к Teku, на Teku..
Если у вас возникли проблемы с вашим клиентом и вам нужно перезапустить всю сеть, вам нужно знать о слабой субъективности. Proof of Work позволяет любому вернуться к основному блоку сети и без доверия построить состояние сети с нуля. У Proof of Stake, однако, есть уловка в этом отношении: если треть сетевых валидаторов на выходе из определенной точки все же продолжает подписывать блоки и аттестацию, они могут изменить состояние сети и передать эти ложные данные на узел, синхронизирующийся с сеть, если злоумышленники поймают узел синхронизации до того, как узел синхронизации достигнет места, где валидаторы сняли свои средства. Вы можете прочитать об этом больше здесь, но краткий ответ заключается в том, что вам нужна либо «контрольная точка слабой субъективности», либо закодированный файл состояния, по сути, архив сети. Teku предоставляет стартовые флаги для обоих.
Последняя проблема, связанная с наказанием, самая серьезная: рубящие удары. Слэширование происходит, когда стейкер работает против правил сети. Это отличается от наказания за то, что он не в сети. Он активно работает против сети, отправляя противоречивую информацию о валидаторах. Есть несколько действительно отличных материалов, чтобы узнать больше о слэшинге и о том, как его предотвратить:
Главный вывод – не запускайте один ключ валидатора на нескольких клиентах. По-видимому, именно это стало причиной первого в истории рубящего события., что произошло 2 декабря. С тех пор было нанесено несколько ударов! Если вы переходите с одного экземпляра на другой, проверьте четыре раза, что у вас не будет двух компьютеров, работающих с одним и тем же ключом:
Папа Бен рассказывает, как есть. Источник
Спецификации конфигурации валидатора AWS + Infura + Teku
Настройка блока My Genesis:
Операционная система: Ubuntu Server 20.04 LTS (HVM) (веб-служба Amazon)
Процессор: Процессор Intel Xeon Platinum серии 8000, 3,1 ГГц. (Веб-сервис Amazon)
Объем памяти: 4 виртуальных ядра, 16 ГБ ОЗУ (Amazon Web Service)
Место хранения: 100 ГБ SSD, 300/3000 операций ввода-вывода в секунду (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. Перейдите на страницу EC2, которая будет выглядеть примерно так:
Нажмите кнопку «Запустить экземпляр». Вы увидите следующий экран:
Операционная система
Здесь мы выбираем, какой образ машины (который я считаю операционной системой) мы хотели бы использовать в нашем виртуальном экземпляре. Я выбираю Ubuntu Server 20.04, который представляет собой серверную среду на базе Linux. Среда Ubuntu Server имеет несколько ключевых отличий по оптимизации от среды рабочего стола Ubuntu. Основное отличие для наших целей заключается в том, что на сервере Ubuntu отсутствует графический интерфейс пользователя (GUI). Куда мы идем, там только командная строка! Возвращает меня в дни Apple II.
После выбора нашей операционной системы мы выбираем тип нашего экземпляра:
Я нахожу это меню довольно сложным, поэтому я немного расскажу о нем для вас. Здесь мы выбираем вычислительное ядро / мощность ОЗУ / процессор для нашей машины. Это «сырая» или «активная память» машины, отдельная от хранилища (жесткого диска) устройства. Думайте об этом как о движке нашего виртуального экземпляра, на котором мы будем запускать нашу операционную систему Ubuntu Server. AWS разделяет их на отдельные семейства экземпляров, которые обозначаются комбинацией букв и цифр в крайнем левом столбце..
Семейства экземпляров имеют разное аппаратное обеспечение, так же как разные автомобильные двигатели имеют разные конфигурации поршней, пробок и топлива для удовлетворения различных требований. Мы сосредоточимся на двух из их семейств «общих вычислений», m5 и t3..
Я выбираю экземпляр m5.xlarge, который предоставляет 4 виртуальных вычислительных ядра (vCPU) и 16 ГБ ОЗУ. После работы в основной сети Ethereum 2.0 в течение дня или около того моя машина не использовала более 4% доступного виртуального ЦП. Как упоминалось выше в разделе «Перспективы будущего», потребности сети Ethereum 2.0 будут только расти. Но в следующие несколько месяцев, при отсутствии каких-либо продолжительных скачков сети, я, скорее всего, буду в порядке с экземпляром m5.large (2 виртуальных ядра / vCPU, 8 ГБ ОЗУ).
Технические люди более сообразительные, чем я, также рекомендовали экземпляр t3.large как разумный вариант для Ethereum 2.0. t3.large имеет 2 виртуальных ЦП и 8 ГБ памяти, как и m5.large, но семейство t3 создано для более «скачкообразной» сетевой активности (скачки ЦП), а не семейство m5, предназначенное для постоянной загрузки ЦП..
Ценообразование
Последнее, о чем следует упомянуть, прежде чем мы перейдем к хранению, – это цена. AWS стоит дорого по сравнению с другими вариантами, такими как Digital Ocean. Вы платите за ЦП (семейство экземпляров) и хранилище (жесткий диск) отдельно в зависимости от того, что вы используете. CPU оплачивается почасово. Поскольку валидаторы должны быть в сети 24 часа, вы можете использовать приведенную ниже таблицу цен (с декабря 2020 г.), чтобы произвести приблизительные расчеты:
Это цены по запросу. AWS предоставляет нечто, называемое Цены на зарезервированные инстансы, где, если вы обещаете иметь виртуальный экземпляр на срок от года до трех лет, вы можете получить скидку до 50-60% по приведенной выше таблице цен. (Спасибо Джейсону Хроману за этот совет!)
На домашней странице EC2 нажмите «Зарезервированные инстансы» в меню слева, как показано ниже:
Нажмите «Купить зарезервированный инстанс»:
Во всплывающем меню введите сведения о типе экземпляра и желаемое количество времени, за которое будет отображаться цена (я выбираю m5.xlarge и 36-месячный срок):
Нажмите «Поиск» и посмотрите варианты цен:
Есть значительная скидка в цене, более 50%, я думаю, но я привязан к ней на три года. После покупки зарезервированного инстанса AWS применяет его к существующему виртуальному ящику или применяет его после запуска. Помните, что сюда НЕ входит дисковое пространство (жесткий диск)..
Примечание. Я пока этого не делаю, так как еще не уверен, что AWS – лучший вариант для индивидуального размещения от одного до трех узлов валидатора Ethereum 2.0.. Я запускаю экземпляр с оплатой по требованию, чтобы посмотреть, как он работает, прежде чем совершать.
Место хранения
Возвращаясь к процессу запуска нашего экземпляра, мы переходим на вкладку «Добавить хранилище».
Блестящие технические специалисты, с которыми я консультировался, рекомендовали объем хранилища SSD общего назначения 100 ГБ. Хранилище обычно не является узким местом для клиентов Eth2. Однако это без запуск полного клиента Eth1. Для хранилища Eth1 консервативная оценка составит около 1 ТБ. Обязательно учтите это, если вы не используете 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 по умолчанию отключает аутентификацию по паролю для доступа к экземпляру. Вы можете использовать только пару ключей, созданную до запуска экземпляра. У пары ключей должен быть файл с расширением .pem, заканчивающийся.
AWS предоставляет простой способ получить вашу команду SSH. Если щелкнуть запущенный экземпляр на главной странице EC2, в правом верхнем углу появится кнопка с надписью «Подключиться»:
На следующей странице будет команда SSH, специфичная для вашего экземпляра. Он будет иметь такую структуру:
ssh -i "PATH_TO_AWS_KEYPAIR.pem" [электронная почта защищена]_IDENTIFIER.compute-ZONE.amazonaws.com
Ввод этой команды в терминал запустит сеанс SSH. В первый раз локальный компьютер спросит, хотите ли вы доверять отпечатку ECDSA, предоставленному AWS. Это сделано для предотвращения атака “человек посередине” и, при необходимости, пользователь может получить отпечаток своего экземпляра, следуя эти шаги.
В терминале отдельно от текущего сеанса SSH перенесите файлы ключей валидатора, необходимые для запуска Teku. В предыдущем сообщении блога мы рассмотрели размещение 32 ETH и получение ключей валидатора для Ethereum 2.0. В итоге у нас осталась такая файловая структура:
eth2deposit-cli / └── validator_key_info / ├── 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 update && sudo apt установить default-jre && sudo apt установить default-jdk
Двойная проверка успешной установки Java:
java -version
Установить двоичный файл
Найдите последнюю стабильную версию 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 / ├── 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
Создайте пользователя без полномочий root
Этот шаг скопирован из Somer Esat’s отличный учебник по Ubuntu / Teku
Мы собираемся создать пользователя без полномочий root по имени teku, который сможет управлять Teku. Введите следующее ниже:
sudo useradd –no-create-home –shell / bin / false teku
Мы также собираемся создать каталог пользовательских данных для Teku, а затем предоставить к нему доступ пользователю teku:
судо mkdir / var / lib / teku && sudo chown -R teku: teku / var / lib / teku
Создать службу systemd
Этот шаг заимствован из Somer Esat’s отличный учебник по Ubuntu / Teku
На этом шаге будет создана служба, которая будет запускать Teku в фоновом режиме. Это также позволит машине автоматически перезапустить службу, если она остановится по какой-либо причине. Это необходимый шаг, чтобы убедиться, что наш валидатор работает круглосуточно..
Создайте служебный файл с помощью текстового редактора nano:
sudo nano /etc/systemd/system/teku.service
В этом файле (который должен быть пустым) мы собираемся поместить ряд команд, которые systemd будет выполнять при запуске службы. Вот код ниже, вам нужно будет добавить следующие элементы, которые мы собрали на этом пути:
- Конечная точка HTTP Infura Eth1
- validator_key_info путь к каталогу с двумя действительными файлами, связанными с ключами
- Пользовательский путь к данным (lib / var / teku)
Поместите эти значения в код, выделенный жирным шрифтом ниже, затем скопируйте все это в текстовый редактор nano:
[Unit] Описание = Узел маяка Teku хочет = network-online.target After = network-online.target [Service] Тип = простой Пользователь = teku Group = teku Restart = always RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku –network = основная сеть –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_keys_KEY56 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore -lock-enabled = false –путь к базе данных = / var / lib / teku [Установить] WantedBy = multi-user.target
Введите команду-X, затем введите «Y», чтобы сохранить изменения.
Мы должны перезапустить «systemctl», чтобы обновить его:
sudo systemctl демон-перезагрузка
Запустите службу:
sudo systemctl start teku
Убедитесь, что все нормально запускается:
sudo systemctl статус teku
Если вы видите какие-либо ошибки, получите более подробную информацию, запустив:
sudo journalctl -f -u teku.service
Вы можете остановить службу Teku, запустив:
sudo systemctl stop teku
Проверьте страницу устранения неполадок Teku на предмет распространенных ошибок или проверить Teku Discord, за которым следит команда.
Как только вы почувствуете, что все улажено, включите перезапуск службы, если она завершится, запустив:
sudo systemctl включить teku
Вот оно что! Все должно быть готово прямо сейчас. При проверке службы Teku вы увидите серию журналов, в которых отмечается событие синхронизации, это ваш валидатор, синхронизирующий цепочку маяков. Как только он достигнет заголовка, эти журналы будут изменены на Slot Event, и вы также увидите свою эффективность аттестации и заблокируйте предложения..
Запуск
Источник: Beaconcha.in
1 декабря в 12:00 по всемирному координированному времени были проверены первые блоки Beacon Chain. Первый блок пришел из Валидатор 19026, с загадочным граффити: «Мистер Ф. был здесь». Двенадцать секунд спустя последовал следующий блок, граффити указывало, что валидатор мог быть Цуг, Швейцария. Цепочка маяков Eth2 неуклонно росла, блок за блоком каждые 12 секунд. Затем возникла следующая проблема: достаточно ли валидаторов будет подключено к сети, чтобы завершить первую эпоху? Да! 82,27% валидаторов подтвердили достоверность Эпохи 0, пресловутого первого этажа Beacon Chain. Вы можете узнать больше о запуске Beacon Chain и о том, что будет дальше, здесь..
Источник: Beaconcha.in
Сейчас мы находимся на Эпохе 760, что означает, что Beacon Chain работает без сбоев почти неделю..
Вот снимок с моей точки зрения момента зарождения, используя настройку, описанную в этом посте:
В следующей части мы кратко рассмотрим, как идут дела. Я собираюсь получить доступ к метрикам из Teku, обсудить стоимость использования AWS и кратко обсудить состояние сети..
Будьте на связи!
Ресурсы и ссылки
Спасибо Джеймсу Беку, Мередит Бакстер, Джейсону Хроману, Аарону Дэвису, Чаминде Дивитотавела, Бену Эджингтону, Темному Шуту, Сомеру Эсату, Джозефу Любину, Коллину Мейерсу, Нику Нельсону, Маре Шмидт, Адриану Саттону и Алексу Тудораче за поддержку и техническую помощь..
Ethereum 2.0Новостная рассылкаПодпишитесь на нашу рассылку, чтобы получать последние новости Ethereum, корпоративные решения, ресурсы для разработчиков и многое другое.