Объявление о слиянии Ropsten

• Ropsten станет первой продолжительной по времени тестовой сетью, проходящей через слияние.
• 30 мая 2022 года была запущена новая сеть Ropsten Beacon Chain для достижения консенсуса в сети.
• Ориентировочно 2 июня 2022 года сеть Ropsten Beacon Chain будет обновлена в соответствии с правилами совместимого со слиянием протокола (Bellatrix) в ячейке 24000.
• После этого будет выбрана конечная общая сложность (TTD) для активации слияния в сети с доказательством работы. Операторы узлов должны будут вручную задать это значение в своих клиентах.
• Еще одно объявление с конкретной конечной общей сложностью для слияния Ropsten будет опубликовано в этом блоге 3 июня 2022 года. Пользователям стоит ждать этого значения TTD через несколько дней после его выбора и быть готовыми к настройке своих клиентов соответствующим образом в кратчайшие сроки.

Контекст

После долгих лет работы по внедрению доказательства владения в Ethereum мы приступаем к финальной стадии тестирования — запуску тестовой сети.

Протестировав клиентские реализации на сетях Kintsugi 🍵, Kiln 🔥🧱 и нескольких теневых ветвлениях, клиентские команды теперь готовы провести слияние в самой старой тестовой сети с моделью доказательства работы — Ropsten. При подготовке для обеспечения консенсуса в сети была запущена цепь Ropsten Beacon Chain.

После перехода Ropsten на модель доказательства владения будут переведены еще две тестовые сети (Goerli и Sepolia), и только затем — основная сеть. Другие тестовые сети, Rinkeby и Kovan, могут поддерживаться и обновляться сообществом по отдельности, но больше не будут контролироваться разработчиками клиентов.

Два способа принципиально отличают это слияние от предыдущих обновлений Ethereum. Во-первых, операторам узлов необходимо обновлять свои клиенты слоя и консенсуса, и исполнения одновременно, а не по одиночке. Во-вторых, обновление активируется в два этапа: первый на высоте ячейки в Beacon Chain, а второй — при достижении значения общей сложности на слое исполнения.

Учитывая эти обстоятельства, сеть Ropsten, которая должна быть признана устаревшей после процесса слияния, будет проходить через обновления раньше, чем прежде, то есть в процессе разработки. Таким образом сообщество получит больше времени на ознакомление с процессом обновления.

Примечание. Перечисленные ниже выпуски клиентов не будут подходить для перехода основной сети Ethereum на модель доказательства владения.

Информация об обновлении

Сроки

Процесс слияния будет состоять из двух этапов. Он начнется с обновления сети на слое консенсуса, запускаемого высотой ячейки. За этим следует переход слоя исполнения от доказательства работы к доказательству владения, который запускается определенным пороговым значением общей сложности под названием конечная общая сложность (Terminal Total Difficulty) (TTD).

2 июня 2022 года в ячейке 24000 обновление Bellatrix подготовит Ropsten Beacon Chain к слиянию. К тому времени клиенты CL начнут получать значение TTD для сети с доказательством работы.

Cкорость хэширования в тестовых сетях с доказательством работы очень переменчива, поэтому значение TTD сначала будет установлено на завышенном уровне — 100000000000000000000000. При текущей скорости хэширования Ropsten на достижение такого значения потребуется примерно 250 лет.

По выполнении обновления Bellatrix в сети Beacon Chain будет выбрано и объявлено новое значение TTD, которое ожидается через несколько дней после этого. Затем пользователям потребуется настроить это новое значение на своем узле. Соответствующие инструкции для каждого клиента доступны здесь.

Когда это новое значение TTD будет достигнуто или превзойдено в Ropsten, начнется часть слоя исполнения в рамках перехода с кодовым именем Paris. Еще раз напомним: скорость хэширования Ropsten, как известно, изменчива, поэтому фактическое время достижения значения конечной общей сложности может колебаться.

Как только слой исполнения превысит значение TTD, следующий блок будет создан полностью валидатором сети Beacon Chain. Слияние будет считаться оконченным сразу после того, как сеть Beacon Chain завершит создание этого блока. При нормальных условиях работы сети это должно произойти в течение 2 эпох (или приблизительно через 13 минут) после попадания в первый блок, созданный после достижения TTD!

Новый завершенный тег блока JSON-RPC возвращает последний оконченный блок или ошибку, если такого блока после слияния не существует. Этот тег может использоваться для приложений, чтобы проверять завершенность слияния. Аналогично, умные контракты могут запрашивать опкод DIFFICULTY (0x44), который после слияния получит имя PREVRANDAO, чтобы определить, произошло ли слияние. Мы рекомендуем поставщикам инфраструктуры следить не только за завершением процесса, но и за общей стабильностью сети.

Выпуски клиентов

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

Как упоминалось выше, следующие релизы имеют жестко закодированное значение конечной общей сложности 100000000000000000000000, которое нужно будет обновить вручную после обновления Bellatrix в сети Beacon Chain.

При выборе клиента для запуска валидаторы должны уделять особое внимание рискам запуска большинства клиентов, как на EL, так и на CL. Пояснение этих рисков и их последствий можно найти здесь. С оценкой текущего распространения клиентов EL и CL, а также руководством для перехода от одного клиента к другому можно ознакомиться здесь.

Примечание. Если вы ранее загрузили выпуск клиента с Ropsten со значением TTD 43531756765713534, вам нужно обновить выпуск или вручную заменить TTD на 100000000000000000000000, как указано здесь.

Слой консенсуса

Примечание для Lodestar. В последней версии Lodestar v0.37.0 установлено устаревшее значение Ropsten TTD 43531756765713534. Для совместимости с сетью Ropsten после слияния, использующей значение TTD 100000000000000000000000, пользователям Lodestar нужно будет вручную переопределить это значение. Инструкции о том, как это сделать, можно найти в публикации с объявлением о выпуске.

Слой исполнения

Примечание для Geth. Последняя версия go-ethereum (geth), Sharblu (v1.10.18), использует устаревшее значение Ropsten TTD 43531756765713534. Для совместимости с сетью Ropsten после слияния, использующей значение TTD 100000000000000000000000, пользователям geth нужно будет выполнить одно из действий ниже.

• Использовать исходный код на последней ветке master.
• Использовать последний образ Docker.
• Вручную переписать значение TTD, запустив следующую команду при запуске клиента: --override.terminaltotaldifficulty 100000000000000000000000.

Спецификации обновлений

Критические изменения консенсуса для слияния указаны в двух местах:

• Слой консенсуса изменяется в каталоге bellatrix репозитория consensus-specs.
• Слой исполнения изменяется в репозитории со спецификациями исполнения Paris spec.

В дополнение к этому две другие спецификации охватывают способы взаимодействия клиентов слоя консенсуса и слоя исполнения:

• Интерфейс Engine API, указанный в репозитории execution-apis, используется для коммуникации между слоями консенсуса и исполнения.
• Спецификация Optimistic Sync, указанная в папке sync репозитория consensus-specs, используется слоем консенсуса для импорта блоков по мере синхронизации клиента слоя исполнения и обеспечивает частичный обзор головы цепочки от первого до последнего значения.

Часто задаваемые вопросы

Что нужно делать оператору узла?

После слияния полный узел Ethereum будет объединять в себе клиент уровня консенсуса, запущенный по модели доказательства владения в сети Beacon Chain, и клиент слоя исполнения, который управляет пользовательским состоянием и запускает вычисления, связанные с транзакциями. Слаженность их работы достигается с помощью аутентифицированного порта и нового набора методов удаленного вызова процедур (RPC) JSON под названием Engine API. Клиенты EL и CL аутентифицируют друг друга с помощью секрета JWT. Операторы узлов могут найти инструкции по их созданию и настройке в документации своих клиентов.

Другими словами, если вы уже управляете узлом в Beacon Chain, теперь вам также нужно будет управлять клиентом слоя исполнения. Аналогично, если вы управляете узлом в текущей сети с доказательством выполнения работы, вам будет необходимо управлять клиентом уровня консенсуса. Для их безопасной связи необходимо передать на каждый клиент токен JWT.

Стоит подчеркнуть: хотя они оба являются частью выпусков клиентов слоя консенсуса, запуск узла Beacon отличается от запуска клиента валидатора. Дольщики должны запускать оба узла, но операторам нужен только первый. В этой публикации более подробно объясняется разница между обоими компонентами.

Также обратите внимание, что каждый слой будет содержать независимый набор пиров и собственный программный интерфейс API. Поэтому программные интерфейсы API Beacon и удаленного вызова процедур (RPC) JSON продолжат работать так, как ожидается.

И не забудьте проверить 6–7 июня объявление в этом блоге с окончательным значением Ropsten TTD.

Что нужно делать дольщику?

Как уже говорилось выше, после слияния валидаторам сети Beacon Chain необходимо будет запустить клиент слоя исполнения, а также клиенты слоя консенсуса. Это настоятельно рекомендовалось до слияния, но валидаторы могли передавать эти обязанности третьим сторонам. Это было возможно, потому что единственными данными, необходимыми для уровня выполнения, были обновления депозитного контракта.

После слияния валидаторы должны удостовериться в том, что транзакции в блоках, которые они создают и подтверждают, действительны. Для этого каждый узел Beacon должен быть связан с клиентом слоя исполнения. Обратите внимание, что несколько валидаторов могут быть связаны с одним узлом передачи сигнала и комбинацией клиентов слоя исполнения. Это расширяет круг обязанностей валидаторов, но также дает валидатору, предлагающему блок, право приоритетного получения комиссии за соответствующие транзакции (которые в настоящее время поступают майнерам).

Вознаграждение для валидатора начисляется в сети Beacon Chain и для снятия требует последующего обновления сети, но комиссии за транзакции будут и далее выплачиваться, сжигаться и распределяться на слое исполнения. Валидаторы могут указывать любой адрес Ethereum в качестве получателя комиссий за транзакции.

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

Если вы внесли свою долю с помощью третьей стороны, именно она должна указать способ распределения комиссий.

Обновления тестовой сети — последняя возможность для валидаторов убедиться, что настройки работают должным образом, и решить проблемы. Информацию о запуске валидатора в сети Ropsten Beacon Chain в рамках подготовки к слиянию можно найти на панели запуска стейкинга Ropsten.

Мы настоятельно рекомендуем, чтобы валидаторы основной сети запускали слияние в Ropsten и других тестовых сетях, прежде чем основная сеть Ethereum перейдет на доказательство владения.

Что делать разработчику приложений или инструментов?

С запуском слияния на Ropsten настало время удостовериться в том, что ваш продукт будет работать надлежащим образом при переходе к доказательству владения и в среде после слияния. Как говорилось в предыдущей публикации, слияние окажет лишь минимальное воздействие на подмножество контрактов, развернутых в Ethereum, и ни один из них не должен быть нарушен. Кроме того, львиная доля пользовательских конечных точек программного интерфейса API остается стабильной (если вы не используете особые методы доказательства работы, такие как eth_getWork).

Тем не менее большинство приложений в Ethereum охватывает гораздо больше, чем контракты в цепи. Теперь вам пора убедиться, что ваш код интерфейса, инструментарий, конвейер развертывания и другие не входящие в цепь компоненты работают так, как задумано. Мы настоятельно рекомендуем разработчикам выполнить полный цикл тестирования и развертывания на Ropsten (или Kiln) и сообщить соответствующим сопроводителям проектов о любых проблемах с инструментами или зависимостями. Если вы не уверены, где следует сообщить о проблеме, используйте этот репозиторий.

Требуются ли какие-либо действия от пользователя Ethereum или владельца эфира?

Нет. Эта тестовая сеть не повлияет на основную сеть Ethereum. До перехода основной сети в этом блоге будут публиковаться последующие объявления.

Требуются ли какие-либо действия от майнера?

Нет. Если вы занимаетесь майнингом в основной сети Ethereum или Ropsten, вам нужно знать, что после слияния она будет функционировать полностью по принципу доказательства владения. После слияния майнинг в ней будет невозможен.

Слияние запланировано примерно на 8 июня 2022 года в Ropsten и позднее в этом году для основной сети Ethereum.

Может ли валидатор снять свою долю?

Нет. Слияние — самое сложное изменение среды Ethereum за все время ее существования. Чтобы свести к минимуму риски нарушения работы сети, был принят минимальный подход, исключающий во время данного обновления любые изменения, не связанные с переходом.

Снятие доли с Beacon Chain, вероятно, будет введено с первым обновлением после слияния. Спецификации для слоев консенсуса и исполнения находятся в процессе разработки.

У меня есть еще вопросы. К кому с ними обратиться?

Созвон сообщества по вопросам слияния запланирован на 3 июня (14:00 UTC). Исследователи и разработчики клиентов смогут ответить на вопросы операторов узлов, стейкеров, поставщиков инструментов и инфраструктуры, а также членов сообщества.

Когда произойдет слияние?

На момент этой публикации дата перехода основной сети Ethereum на доказательство владения еще не определена. Если кто-то утверждает противоположное, то это, скорее всего, мошенник. Обновления будут публиковаться в этом блоге. Будьте бдительными!

Если никаких проблем с Ropsten не возникнет, другие тестовые сети Ethereum будут проходить через слияние после завершения тестирования клиента. После успешного перехода и стабилизации сетей Goerli и Sepolia будет выбрана высота ячейки для обновления Bellatrix в сети Beacon Chain, а также будет установлено значение сложности для перехода основной сети. Затем клиенты создают выпуски, которые включают слияние на основной сети. Они будут объявлены в этом блоге и других публикациях сообщества.

Предполагается, что никаких проблем не возникнет. Но если на каком-либо этапе процесса появятся проблемы или тестовое покрытие будет недостаточным, эти вопросы будут решены до продолжения развертывания.

Только после этого можно будет определить точную дату слияния.

Иными словами, 🔜.