Reason to trust
How Our News is Made
Strict editorial policy that focuses on accuracy, relevance, and impartiality
Ad discliamer
Morbi pretium leo et nisl aliquam mollis. Quisque arcu lorem, ultricies quis pellentesque nec, ullamcorper eu odio.
Нулевая стадия Ethereum 2.0, которая активирует алгоритм Proof-of-Stake (PoS), планируется к запуску 3 июня 2020 года.
Один из разработчиков Ethereum 2.0 Джастин Дрейк сообщил о планах запустить нулевую стадию проекта 3 июня 2020 года. Дата выбрана неслучайно: это будет 11-ая годовщина со дня эмиссии первого блока (Genesis Block) в сети биткоина.
Спецификации запуска нулевой стадии Ethereum 2.0 планируется опубликовать через две недели – 30 июня 2019 года, добавил Дрейк.
До запуска нулевой стадии разработчикам ETH 2.0 предстоит пройти два ключевых этапа. Во-первых, создать депозитный контракт, на который валидаторы транзакций, работающие по PoS-алгоритму, смогут зачислять свои средства. Церемония запуска контракта состоится в ходе конференции Devcon, запланированной на 8-10 октября в Японии. Ожидается, что на депозит будут размещены не менее 2 млн ETH.
Второй важной вехой в подготовке к нулевой стадии станет сам запуск и эмиссия первого блока в новой сети Ethereum.
«Это произойдет после Рождества и нового года, символизируя новую эпоху для Ethereum», – говорится в статье Trustnodes. К этому моменту специальный счет будет уже три месяца аккумулировать депозиты валидаторов.
В настоящее время запущены по меньше мере три тестовых сети Ethereum 2.0, каждая из которых использует собственного клиента. Предполагается, что следующим этапом станет создание единой тестовой сети с поддержкой нескольких клиентов. Ее запуск может состояться через несколько недель.
После нулевой стадии сеть перейдет на первую – промежуточную – стадию, а следом на вторую стадию, которая предполагает полный шардинг. Вторая стадия Ethereum 2.0 будет запущена через два года.
Сейчас дискуссия разворачивается также вокруг вопроса о том, что произойдет с сетью Ethereum 1.0. Сначала предполагалось, что она будет организована в отдельный шард, однако Дрейк утверждает, что такое решение потребует значительных усилий в контексте разработки и управления. В качестве альтернативного сценария рассматривается возможность создания инструмента для обеспечения совместимости двух протоколов.
