- Для слияния Ropsten было выбрано значение конечной общей сложности (TTD) 50000000000000000.
- Дольщики и операторы узлов должны вручную переписать значение TTD в клиентах слоев исполнения и консенсуса до 7 июня 2022 года.
- У тестовых сетей с доказательством работы могут быть переменные скорости хэширования, поэтому точное время слияния на Ropsten сложно предсказать. Если неожиданных колебаний скорости хэширования не будет, слияние должно произойти примерно 8–9 июня 2022 года.
- Обратите внимание: синхронизация клиента слоя исполнения в сети Ropsten может занять от нескольких часов до нескольких дней и является обязательной для работы после слияния.
Контекст
Ранее на этой неделе было объявлено о переходе тестовой сети Ropsten на модель доказательства владения. Из-за нестабильности скорости хэширования в тестовых сетях с доказательством работы выпуски клиентов, поддерживающие обновление, были настроены с использованием искусственно завышенного значения конечной общей сложности (TTD). Это гарантировало, что слияние не будет запущено до готовности сети Ropsten Beacon Chain.
Вчера в ячейке 24000 в сети Ropsten Beacon Chain было активировано обновление Bellatrix, готовящее сеть к работе после слияния. Для запуска перехода было выбрано новое значение TTD: 50000000000000000.
Операторам узлов и дольщикам необходимо вручную установить это значение TTD в клиентах слоев исполнения и консенсуса, прежде чем сеть достигнет указанной общей сложности. Текущая общая сложность сети является частью заголовка блоков и может быть получена по запросу вашего узла или через инструмент изучения блоков.
Если не будет никаких неожиданных изменений скорости хэширования, достижение этой общей сложности и превышение значения TTD ожидается 8–9 июня 2022 года.
Версии клиентов для слияния Ropsten
Чтобы перезаписать конечную общую сложность, операторам узлов и дольщикам необходимо запустить указанные или более новые версии клиентов. Обратите внимание: до слияния клиенты слоев консенсуса и исполнения должны быть полностью синхронизированы, при этом клиентам слоя исполнения для этого может понадобиться от нескольких часов до нескольких дней.
Слой консенсуса
| Название | Версия | Ссылка |
|---|---|---|
| Lighthouse | Baby Wizard (2.3.0) | Скачать |
| Lodestar | v0.37.0 | Скачать |
| Prysm | v2.1.3-rc.2 | Скачать |
| Nimbus | v22.5.2 | Скачать |
| Teku | v22.5.2 | Скачать |
Слой исполнения
| Название | Версия | Ссылка |
|---|---|---|
| Besu | v22.4.2 | Скачать |
| Erigon | v2022.05.08 | Скачать |
| go-ethereum (geth) | v1.10.18 | Скачать |
| Nethermind | v1.13.1 | Скачать |
🚨 (НЕ ЯВЛЯЕТСЯ ЧАСТЬЮ ЭТОЙ ПУБЛИКАЦИИ.) ИСПОЛЬЗУЙТЕ ОДНО ИЗ ПРИМЕЧАНИЙ НИЖЕ В ЗАВИСИМОСТИ ОТ СТАТУСА ВЫПУСКА ERIGON. 🚨
(🚨1🚨) Примечание для Erigon. Версия v2022.05.08 совместима со слиянием Ropsten, но рекомендуем обновиться до версии vXXX, содержащей несколько улучшений, связанных со слиянием.
(🚨2🚨) Примечание для Erigon. Версия v2022.05.08 совместима со слиянием Ropsten, но вскоре должен появиться новый выпуск Erigon, содержащий несколько улучшений, связанных со слиянием. Чтобы сделать работу удобнее, пользователи должны обновиться сразу после выхода новой версии.
Перезапись конечной общей сложности
Чтобы вовремя активировать слияние, операторам узлов и дольщикам необходимо в клиентах обоих слоев, исполнения и консенсуса, перезаписать значение конечной общей сложности (TTD) на 50000000000000000.
Инструкции для каждого клиента приведены ниже.
Слой исполнения
Besu
- При использовании файлов конфигурации TOML добавьте следующую строку: override-genesis-config=["terminalTotalDifficulty=50000000000000000"].
- Или при запуске узла с помощью CLI добавьте следующий флаг: --override-genesis-config="terminalTotalDifficulty=50000000000000000".
Erigon
- При запуске узла с помощью CLI добавьте следующий флаг: --override.terminaltotaldifficulty=50000000000000000.
Go-Ethereum (geth)
- При запуске узла с помощью CLI добавьте следующий флаг: --override.terminaltotaldifficulty 50000000000000000.
Nethermind
- При запуске узла с помощью CLI добавьте следующий флаг: --Merge.TerminalTotalDifficulty 50000000000000000.
- Это можно сделать в файле конфигурации вашего клиента или в переменных среды, установив значение TerminalTotalDifficulty 50000000000000000.
Слой консенсуса
Lighthouse
- При запуске узла с помощью CLI добавьте следующий флаг: --terminal-total-difficulty-override=50000000000000000.
Lodestar
- При запуске узла с помощью CLI добавьте следующий флаг: --terminal-total-difficulty-override 50000000000000000.
- Узнать больше можно в этой публикации.
Nimbus
- При запуске узла с помощью CLI добавьте следующий флаг: --terminal-total-difficulty-override=50000000000000000.
Prysm
- При запуске узла с помощью CLI добавьте следующий флаг: --terminal-total-difficulty-override 50000000000000000.
- Это также можно задать в файле config.yaml, обновив значение TOTAL_TERMINAL_DIFFICULTY в каталоге конфигурации и перезапустив клиент.
Teku
- При запуске узла с помощью CLI добавьте следующий флаг: --Xnetwork-total-terminal-difficulty-override=50000000000000000.
Часто задаваемые вопросы
Что требуется от оператора узла или дольщика?
Как упоминалось в объявлении о слиянии Ropsten, операторам узлов и дольщикам в Ropsten необходимо обновить свои клиенты слоев исполнения и консенсуса до указанных выше версий или более новых.
Затем операторам узлов и дольщикам нужно вручную перезаписать значение конечной общей сложности (TTD) Ropsten в клиентах и слоя исполнения, и слоя консенсуса, используя команды выше.
И убедитесь, что клиенты обоих слоев, консенсуса и исполнения, полностью синхронизированы перед слиянием. Клиентам слоя исполнения на это может понадобиться до нескольких дней.
Что требуется от разработчика приложений или инструментов?
С запуском слияния на Ropsten настало время удостовериться в том, что ваш продукт будет работать надлежащим образом при переходе к доказательству владения и в среде после слияния. Как говорилось в предыдущей публикации, слияние окажет лишь минимальное воздействие на подмножество контрактов, развернутых в Ethereum, и ни один из них не должен быть нарушен. Кроме того, львиная доля пользовательских конечных точек программного интерфейса API остается стабильной (если вы не используете специальные методы доказательства работы, такие как eth_getWork).
Однако большинство приложений в Ethereum охватывает гораздо больше, чем контракты в цепи. Теперь вам пора убедиться, что ваш код интерфейса, инструментарий, конвейер развертывания и другие не входящие в цепь компоненты работают так, как задумано. Мы настоятельно рекомендуем разработчикам выполнить полный цикл тестирования и развертывания в сети Ropsten (или Kiln) и сообщить соответствующим сопроводителям проектов о любых проблемах с инструментами или зависимостями. Если вы не уверены, где следует сообщить о проблеме, используйте этот репозиторий.
Требуется ли что-нибудь от пользователей Ethereum или владельцев эфира?
Нет. Эта тестовая сеть не повлияет на основную сеть Ethereum. Перед переходом основной сети в этом блоге появятся последующие объявления.
Требуется ли что-нибудь от майнеров?
Нет. Если вы занимаетесь майнингом в основной сети Ethereum или Ropsten, вам нужно знать, что после слияния каждая из этих сетей будет полностью функционировать по принципу доказательства владения. После слияния майнинг в таких сетях будет невозможен.
Слияние запланировано примерно на 8–9 июня 2022 года в Ropsten и позднее в этом году для основной сети Ethereum.
Когда произойдет слияние?
На момент этой публикации дата перехода основной сети Ethereum на доказательство владения еще не определена. Если кто-то утверждает противоположное, то это, скорее всего, мошенник. Новости будут публиковаться в этом блоге. Будьте бдительными!
Если никаких проблем с Ropsten не возникнет, другие тестовые сети Ethereum будут проходить через слияние после завершения тестирования клиентов. После успешного перехода и стабилизации сетей Goerli и Sepolia будет выбрана высота ячейки для обновления Bellatrix в сети Beacon Chain, а также будет установлено значение конечной общей сложности для перехода основной сети. Затем появятся выпуски клиентов, позволяющие выполнить слияние в основной сети. Об этом будет объявлено в этом блоге и других публикациях сообщества. Изображение ниже иллюстрирует этот процесс.
Обратите внимание: здесь предполагается, что каждый шаг будет выполняться в соответствии с ожиданиями. Если на каком-либо этапе процесса появятся проблемы или тестовое покрытие будет недостаточным, эти вопросы необходимо будет решить, прежде чем продолжать развертывание.
Только после этого можно будет определить точную дату слияния.
Иными словами, 🔜.