Переход Ethereum на Proof-of-Stake — The Merge — близок:создаются сети разработчиков, дорабатываются спецификации, и всерьез началась работа с сообществом. Слияние спроектировано таким образом, чтобы оказывать минимальное влияние на то, как Ethereum работает для конечных пользователей, смарт-контрактов и децентрализованных приложений. Тем не менее, есть некоторые незначительные изменения, на которые стоит обратить внимание. Прежде чем мы углубимся в них, вот несколько ссылок, чтобы предоставить информацию об общей архитектуре слияния:
В оставшейся части этого поста предполагается, что читатель знаком с вышеизложенным. Для тех, кто хочет копнуть еще глубже, полные спецификации The Merge доступны здесь:
После слияния блоки доказательства работы больше не будут существовать в сети. Вместо этого прежнее содержание доказательства работы становится компонентом блоков, созданных в цепочке маяков. Затем вы можете думать о Beacon Chain как о новом уровне консенсуса Proof-of-Stake в Ethereum, заменяющем предыдущий уровень консенсуса Proof-of-Work. Цепные блоки маяка будут содержать ExecutionPayloads , которые после слияния являются эквивалентом блоков в текущей цепочке проверки работоспособности. На изображении ниже показана эта связь:
Для конечных пользователей и разработчиков приложений эти ExecutionPayloads где происходит взаимодействие с Ethereum. Транзакции на этом уровне по-прежнему будут обрабатываться клиентами уровня исполнения (Besu, Erigon, Geth, Nethermind и т. д.). К счастью, из-за стабильности уровня выполнения слияние вносит лишь минимальные критические изменения.
После слияния несколько полей, ранее содержавшихся в заголовках блоков доказательства работы, становятся неиспользуемыми, поскольку они не имеют отношения к доказательству доли. Чтобы свести к минимуму нарушение работы инструментов и инфраструктуры, эти поля устанавливаются равными 0 или их эквиваленту в структуре данных, а не полностью удаляются из структуры данных. Полные изменения в полях блоков можно найти в EIP-3675.
оммерс [] RLP([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256(RLP([])) сложность 0 одноразовый номер 0x00000000000000000 Поскольку доказательство доли не создает оммеры (так называемые «дядей-блоки») естественным образом, как доказательство работы, их список в каждом блоке (оммеры ) будет пустым, а хэш этого списка (ommersHash ) станет хэшем пустого списка в кодировке RLP. Точно так же, поскольку трудность и nonce являются функциями доказательства работы, для них будет установлено значение 0 , соблюдая их значения размера в байтах.
mixHash , еще одно поле, связанное с майнингом, не будет установлено на 0, а вместо этого будет содержать значение RANDAO цепочки маяков. Подробнее об этом ниже.
BLOCKHASH &СЛОЖНОСТЬ изменения кодов операций После слияния BLOCKHASH код операции по-прежнему будет доступен для использования, но, учитывая, что он больше не будет подделываться в процессе хэширования с доказательством работы, псевдослучайность, обеспечиваемая этим кодом операции, будет намного слабее.
Соответственно, СЛОЖНОСТЬ код операции (0x44 ) будет обновлен и переименован в RANDOM . После слияния он вернет выходные данные маяка случайности, предоставленного цепочкой маяков. Таким образом, этот код операции будет более сильным, хотя и предвзятым, источником случайности для разработчиков приложений, чем BLOCKHASH .
Значение, предоставляемое RANDOM будет храниться в ExecutionPayload где mixHash , значение, связанное с вычислением доказательства работы, было сохранено. mixHash полезной нагрузки. поле также будет переименовано в random .
Вот иллюстрация того, как СЛОЖНОСТЬ &СЛУЧАЙНЫЙ коды операций работают до и после слияния:
Перед слиянием мы видим 0x44 код операции возвращает сложность поле в заголовке блока. Код операции после слияния переименован в RANDOM. , указывает на поле заголовка, которое ранее содержало mixHash и теперь сохраняет случайный значение из состояния цепочки маяков.
Это изменение, формализованное в EIP-4399, также предоставляет ончейн-приложениям способ оценить, произошло ли слияние. Из EIP:
<цитата> Кроме того, изменения, предлагаемые этим EIP, позволяют смарт-контрактам определять, произошло ли уже обновление до PoS. Это можно сделать, проанализировав возвращаемое значение кода операции DIFFICULTY. Значение больше 2**64 указывает, что транзакция выполняется в блоке PoS.
Слияние повлияет на среднее время блока в Ethereum. В настоящее время на этапе доказательства работы блоки приходят в среднем каждые ~13 секунд с изрядной разницей в фактическом времени блока. При подтверждении доли блоки приходят ровно каждые 12 секунд, за исключением случаев, когда слот пропущен либо из-за того, что валидатор не в сети, либо из-за того, что он не отправил блок вовремя. На практике в настоящее время это происходит в <1% слотов.
Это означает сокращение среднего времени блока в сети примерно на 1 секунду. Смарт-контракты, которые предполагают определенное среднее время блока в своих расчетах, должны учитывать это.
Под доказательством работы всегда есть потенциал для реорганизации. Приложения обычно ждут, пока несколько блоков будут добыты поверх новой головы, прежде чем считать, что она вряд ли будет удалена из канонической цепочки или «подтверждена». Вместо этого после слияния у нас есть концепции finalized. и безопасная голова блоки. Эти блоки могут использоваться даже более надежно, чем «подтвержденные» блоки подтверждения работы, но для их правильного использования требуется сдвиг в понимании.
Завершенный блок — это блок, который был принят как канонический более чем 2/3 валидаторов. Чтобы создать конфликтующий блок, злоумышленник должен сжечь не менее 1/3 общей доли. На момент написания этой статьи это составляет более 10 млрд долларов (или>2,5 млн ETH) на Ethereum.
Безопасная голова Блок — это тот, который при нормальных сетевых условиях мы ожидаем включить в каноническую цепочку. При сетевых задержках менее 4 секунд, честном большинстве валидаторов и отсутствии атак на правило выбора ветвления, безопасная голова никогда не останется сиротой. Презентация с подробным описанием расчета безопасного напора для различных сценариев доступна здесь. Кроме того, предположения и гарантии безопасной головы формально определяются и анализируются в следующем документе.
После слияния API уровня выполнения (например, JSON RPC) вернут безопасный заголовок. по умолчанию при запросе последней блокировать. В нормальных сетевых условиях безопасная головка и фактический конец цепи будет эквивалентен (с безопасным отставанием головы всего на несколько секунд). Безопасные головы будет меньше шансов быть реорганизованным, чем текущее доказательство работы последнее блоки. Чтобы раскрыть фактическую вершину цепочки проверки ставок, unsafe флаг будет добавлен в JSON RPC.
Завершенные блоки также будут доступны через JSON RPC через новый finalized. флаг. Затем они могут служить более надежной заменой подтверждениям работы. В приведенной ниже таблице обобщается это:
последняя Ожидаемый, должен использоваться с осторожностью. голова Подтверждение доли небезопасно Ожидаемый, должен использоваться с осторожностью. безопасная голова Подтверждение доли последняя Возможно, требуется либо большая задержка в сети, либо атака на сеть. подтверждено Доказательство работы Н/Д Маловероятно, требуется большая часть хешрейта для майнинга конкурирующей цепочки глубиной> # подтверждений. завершено Подтверждение доли завершено Крайне маловероятно, требуется> 2/3 валидаторов для завершения конкурирующей цепочки, требующей сокращения как минимум 1/3. Мы надеемся, что этот пост поможет разработчикам приложений подготовиться к долгожданному переходу на доказательство доли. В ближайшие несколько недель долгоживущая тестовая сеть будет доступна для тестирования более широким сообществом. Кроме того, в сообществе Merge ожидается призыв к разработчикам инфраструктуры, инструментов и приложений, чтобы они задавали вопросы и узнавали последние технические обновления о The Merge. До встречи 👋🏻
<ч />Спасибо Михаилу Калинину за предоставление основного содержания раздела «Безопасная голова», а также Дэнни Райану и Мэтту Гарнетту за рецензирование черновиков этого поста.