Тестовая сеть Athena

Основная команда Obol последние несколько месяцев усердно работала над созданием нашего клиента промежуточного программного обеспечения Distributed Validator и запуском внутренних сетей разработки.

Пришло время проверить Харона более широким сообществом Операторов Узлов. Сегодня мы анонсируем первую общедоступную тестовую сеть Obol; Athena и наша дорожная карта для клиента, готового к основной сети.

Обзор & tl;dr

• Путешествие по тестовой сети
• Будущие тестовые сети
• Готовность основной сети
• Отказ от ответственности
• Форма регистрации в тестовой сети
• Дискорд-сообщество
• Страница найма

Путешествие Athena

Технология распределенного валидатора (DVT) позволяет одному валидатору Ethereum работать на нескольких машинах. Теоретически все эти машины могут контролироваться одним лицом, однако мы стремимся использовать DVT среди групп, где комбинация операторов сотрудничает для запуска валидаторов Ethereum. Имея это в виду, эта и будущие тестовые сети потребуют совместной работы групп людей для запуска узлов. Это потребует больших накладных расходов, но также необходимо, чтобы сделать Ethereum более устойчивым и способствовать децентрализации. Сеть Obol направлена ​​​​на то, чтобы способствовать минимальному доверию в группах, чтобы люди могли создавать, тестировать, запускать и координировать распределенные валидаторы.

Участие в этой тестовой сети позволит вам работать вместе с другими операторами узлов по всему миру, что, как я надеюсь, приведет к более сильному и взаимосвязанному сообществу Obol.

Запуск распределенных валидаторов в составе группы означает, что существует по крайней мере один синхронный случай, когда группа операторов должна собраться вместе и выполнить церемонию генерации распределенного ключа (DKG). Кроме этого, все остальные действия должны выполняться асинхронно.

Путешествие тестовой сети будет выглядеть следующим образом:

Фаза I

Откроется форма приема тестовой сети . В этой форме будет запрашиваться такая информация, как ваше приблизительное геопозиционирование, чтобы связать вас с другими операторами. Вам нужно будет ненадолго запустить клиент Charon, чтобы сгенерировать закрытый ключ ENR для использования в запланированной церемонии генерации распределенного ключа. В рамках этого процесса мы запросим некоторую личную информацию, чтобы снизить вероятность атак Сивиллы. По этой причине, пожалуйста, заполните форму только один раз. Кроме того, регистрация в тестовой сети через форму приема не гарантирует выбора.

Фаза II

Как только мы получим нашу первоначальную группу заявок, следующим этапом будет координация распределенных церемоний генерации ключей среди участников. Каждый выбранный заявитель на тестовую сеть получит сообщение от основной группы Obol, информирующее их о кластере операторов, к которому они были отнесены. У этих операторов будет 7-дневное окно для согласования звонка или времени, когда они будут вместе выполнять DKG. Этот процесс займет всего пару минут, если все пойдет хорошо.

Когда все операторы принимают участие в DKG, создается следующая информация:

• Каждый оператор получает свои приватные ключи для распределенного валидатора. Затем они загружают эти файлы в свой клиент-валидатор.
• Создается файл блокировки кластера, в котором перечислены все распределенные валидаторы, для которых будет работать этот кластер. Этот файл содержит информацию, используемую Хароном для координации кластера, и будет использоваться основной группой для проверки того, действительно ли был создан распределенный валидатор.
• Депозитные файлы валидатора будут созданы для активации валидатора с депозитным контрактом.

Один оператор должен будет загрузить файлы депозита и файл блокировки кластера с основной командой Obol через вторую Typeform (которой мы поделимся в свое время), тем самым подготовив этап для активации распределенного валидатора.

Фаза III

На момент написания статьи в очереди на активацию Prater в настоящее время находится около 18 000 валидаторов . Это означает, что каждому валидатору нужно будет подождать примерно две недели перед активацией. После того, как команда Obol получит данные депозита распределенного валидатора с церемонии DKG каждого оператора, мы отправим эти данные в депозитный контракт вместе с 32 эфирами, чтобы начать процесс активации.

Ожидая в очереди на активацию, операторы узлов будут получать периодические проверки от основной группы, чтобы убедиться, что они будут готовы пройти проверку для этого валидатора, как только он станет активным. Операторов попросят подтвердить, что у них синхронизированы клиенты маяка тестовой сети и что они открыли необходимые порты для общедоступного Интернета для каждого узла Charon для связи друг с другом.

Все идет хорошо, и как только валидатор будет активирован, распределенный кластер валидаторов начнет свою работу. Намерение состоит в том, чтобы запустить эту тестовую сеть в течение 28 дней.

Фаза IV

Примерно через месяц работы мы будем считать эту тестовую сеть Athena завершенной. Последняя задача для операторов будет заключаться в том, чтобы быть хорошими распорядителями тестовой сети и выходить из своего валидатора из сети, а не просто выключать его без выхода. Все операторы, которые успешно выходят из своего валидатора, получат более высокую оценку своей производительности, чем операторы, которые не могут правильно выйти из своего валидатора.

На этом этапе тестовая сеть будет считаться завершенной. Основная команда потратит несколько недель на сбор информации и анализ наблюдаемой производительности всех распределенных валидаторов. Производительность будет оцениваться, и будет опубликован подробный исследовательский пост с описанием сильных и слабых сторон, выявленных в клиенте, и всего процесса UX создания и запуска распределенного валидатора.

Эта дата также совпадает с началом Dappcon (12-14 сентября) и EthBerlin (16-18 сентября). Команда Obol будет спонсировать и представлять оба мероприятия, и мы намерены пригласить участников тестовой сети на итоговое мероприятие на этой неделе в Берлине. Подробности ниже.

Будущие тестовые сети

Дорожная карта тестирования Оболя более подробно изложена здесь . Ближайшей следующей целью тестирования является запуск сети атаки, направленной на поиск дополнительных проблем с Хароном, когда он подвергается атаке. Это будет известно как Bia Attack Net и будет развернуто в сотрудничестве с платформой Bug Bounty. После этого планируется запустить распределенные валидаторы в масштабе цепочки Gnosis для общедоступной тестовой сети 2 с более высокой нагрузкой и более высокими ставками под названием Cerce .

Готовность основной сети

Ниже приводится краткое описание того, как основная команда Obol оценивает готовность основной сети Charon и сопутствующих инструментов и смарт-контрактов. Этот список не является исчерпывающим и может быть дополнен в будущем.

• Публичные тестовые сети завершены на Goerli + Gnosis Chain (также известный как счастливый путь). Клиент должен быть стабильным и простым в использовании и отладке, а валидатор должен быть таким же прибыльным, как и обычный валидатор с одним экземпляром.
• Атакующие сети и красно-синие сети завершены (также известный как несчастный путь). Клиент должен быть устойчив к атакам DoS и олицетворению. Операторы должны иметь возможность менять ключи Харона, если это необходимо/компрометировано. Выход из валидатора должен быть простым в сценарии, когда кластер не может оставаться в сети.
• Харон прошел аудит.
• Любые пользовательские смарт-контракты, связанные с депозитным договором, проверяются.
• Панель запуска DV завершена, и операторы могут самостоятельно пройти весь процесс создания и активации распределенного валидатора.
• Мониторинг производительности Charon понятен и доступен. Понимание того, какой оператор в кластере находится в автономном режиме или работает неэффективно, должно быть простым для определения и исправления.
• Устойчивость к обновлению сети. Клиенты Charon должны иметь возможность без проблем работать через запланированное обновление сети, такое как хардфорк Capella.
• Протокол LMD-GHOST с поддержкой повышения уровня предложения. В настоящее время консенсус BFT Харона не учитывает, является ли предложенный лидером блок оптимальным с точки зрения правила выбора форка, чтобы быть полностью готовым к основной сети, распределенные валидаторы должны знать о «правильном» блоке, который будет предложен с учетом выбора форка. Невыполнение этого требования потенциально может позволить византийскому члену кластера DV предпринять короткую реорганизацию, убедив кластер предложить действительный блок, который не является самым правильным в соответствии с выбором форка. Это может помешать стабильности сети и прибыльности валидатора, если он регулярно предлагает неоптимальные блоки, которые разветвляются.
• Готовность MEV-Boost/PBS. Что касается проблем с предложением блоков, то возможность поддержки слепых блоков маяков и MEV-boost или ретрансляторов является требованием для готовности основной сети.
• Согласование версии. Кластеры Charon должны иметь возможность плавно координировать свои обновления протоколов, выполняя обновление до последней спецификации протокола, поддерживаемой всеми узлами в кластере, когда все клиенты используют версию программного обеспечения, поддерживающую предлагаемую версию протокола.
• Все обязанности выполнены. В настоящее время Charon поддерживает аттестации и блокирует предложения. Агрегации и обе обязанности комитета по синхронизации должны быть выполнены для готовности основной сети. Подробнее об этом в будущем сообщении в блоге.

Отказ от ответственности

Charon — это раннее альфа-клиентское программное обеспечение, которое не готово к использованию в основной сети. В настоящее время он должен стать более удобным для пользователя, устойчивым и проверенным в боевых условиях. Если вы решите принять участие в этой тестовой сети, вы улучшите основную технологию в битве за сохранение децентрализованности Proof-of-Stake Ethereum. Кандидаты не должны принимать участие в этой тестовой сети в надежде на какую-либо компенсацию.

Кроме того, участники тестовой сети будут сгруппированы с другими операторами узлов, чтобы совместно запускать распределенные валидаторы как часть команды. Если вы не собираетесь завершать программу тестовой сети, операторы вашего кластера могут сделать невозможным успешное завершение программы без вас. Пожалуйста, не принимайте участие в тестовой сети, если вы не уверены, что сможете управлять узлом более двух месяцев. Недостаточная производительность поставит под угрозу вашу репутацию и участие в будущей деятельности сети Obol.

Зарегистрироваться

Если вышеизложенное звучит для вас хорошо, и вы хотите принять участие в первой тестовой сети Obol, зарегистрируйте свой интерес к следующей Typeform и присоединитесь к нашему Discord . Мы свяжемся с вами, когда придет время настроить распределенный валидатор. Здорово, что ты на борту!