Часть III · Глава 26 из 43 · Paris · The Merge

EIP-3675: замена двигателя Ethereum на лету

Proof of work защищал Ethereum, сжигая энергию — безопасность равнялась хешрейту. The Merge заменил этот двигатель на proof of stake, сохранив тот же самый EVM, аккаунты и историю. Хитрость в том, чтобы не запускать PoS «на месте». Сначала запустить его на отдельной beacon-цепочке, а затем передать штурвал при фиксированной сложности.

Обновлено 23 июн. 2026 г. · 12 мин
Предполагается
  • основы proof of work
  • блоки и fork choice

The Merge часто описывают как «Ethereum перешёл на proof of stake», и эта формулировка приуменьшает, насколько деликатной была операция. Представьте замену двигателя самолёта в полёте, без того, чтобы пассажиры — EVM, каждый аккаунт, вся история транзакций — заметили хоть какую-то тряску. Жёсткое требование EIP-3675 именно таково: изменить то, как согласуются блоки, сохранив всё, что блоки содержат, побайтово идентичным. Нельзя просто переключить proof of work на proof of stake одним форком и надеяться, что новая безопасность выдержит. Давайте выведем, как это было сделано на самом деле.

1 шаг Безопасность как сожжённая энергия

Проблема: платить за безопасность электричеством

При proof of work Правило консенсуса, при котором для производства валидного блока нужно найти nonce, делающий хеш блока меньше целевого значения. Единственный способ — перебирать огромное число значений nonce, так что производство блока стоит реальных вычислений — а значит, и электричества. каждый майнер соревнуется в подборе nonce, делающего хеш его блока достаточно малым. Единственная стратегия — перебирать астрономическое число вариантов, так что безопасность цепочки буквально пропорциональна тому, сколько хеширования — а значит, и электричества — тратится. Чтобы атаковать цепочку, нужно перехешировать всех остальных, а это дорого; но честная безопасность стоит той же энергии, оплачиваемой вечно, плюс эмиссия для вознаграждения майнеров и постепенная централизация в сторону тех, у кого дешевле энергия и оборудование.

proof of work — гонка за угадыванием nonce, сжигание энергии miner A nonce 0x9c4a nonce 0x1f7e miner B nonce 0x3a12 nonce 0x8b03 miner C nonce 0x77ec nonce 0x2d99 затраченная энергия ⚡ всегда растёт — тратится, не возвращается первый верный хеш побеждает — безопасность = хешрейт больше безопасности = больше хешрейта: энергия, централизация, эмиссия
При proof of work майнеры жгут энергию, соревнуясь в подборе nonce; первый, кто найдёт валидный хеш, получает блок. Безопасность масштабируется вместе с суммарным хешрейтом — а значит, это непрерывное электричество, эмиссия для оплаты майнеров и централизация в сторону дешёвой энергии.

Мы хотим сохранить содержимое цепочки — EVM, аккаунты, балансы, код контрактов, всю историю — и заменить только двигатель, определяющий, какой блок следующий, поменяв «сжечь энергию, чтобы победить» на «застейкать ETH и получить слэшинг за обман».

→ Шаг 2: сначала строим новый двигатель в стороне.

2 шаг Запускаем PoS параллельно

Не запускаем на месте — ведём beacon-цепочку параллельно

Проблема холодного старта решается тем, что старт делают не холодным. Запустите систему proof of stake как отдельную цепочку beacon-цепочка (beacon chain) Самостоятельная цепочка proof of stake, запущенная в декабре 2020 года. Она вела валидаторов, аттестации и финальность без пользовательских транзакций и без EVM — исключительно чтобы вырастить застейканное множество валидаторов и доказать, что консенсус работает, прежде чем взять управление на себя. — заблаговременно. Начиная с декабря 2020 года она по-настоящему работала на proof of stake: валидаторы вносили депозит в 32 ETH, производили и аттестовали beacon-блоки, добивались финальности — но эти блоки не несли никакой исполняемой нагрузки. Ни EVM, ни пользовательских транзакций — только консенсус, накапливающий большое, проверенное в бою множество валидаторов и стейка, пока PoW-цепочка занималась настоящей работой.

сначала PoS работает параллельно — проверка на практике beacon-цепь PoS · без payload slot 1 slot 2 slot 3 slot 4 цепь исполнения PoW blk 1 blk 2 blk 3 blk 4 бикон-чейн (2020) вёл PoS параллельно, копя валидаторов и финальность
Beacon-цепочка работала на proof of stake параллельно начиная с декабря 2020 года — валидаторы, аттестации, финальность, — но её блоки не несли исполняемой нагрузки. Тем временем исходная цепочка продолжала производить блоки под proof of work. Две цепочки, бок о бок.

К моменту The Merge proof of stake был не экспериментом, включённым под нагрузкой, — за ним стояли почти два года и миллионы застейканных ETH. Оставалось лишь соединить их: позволить проверенной PoS-цепочке начать выбирать блоки исполнения.

→ Шаг 3: выбираем финишную черту, которую майнеры не смогут подделать.

3 шаг Передача при TTD

Передача управления при Terminal Total Difficulty

Нужна точка переключения, которую никто не сможет ускорить или задержать. Высоту блока можно пропустить или оспорить; вместо этого используем накопленную работу. Каждый блок PoW добавляет свою сложность к бегущей суммарной сложности, и The Merge срабатывает при заранее согласованном пороге Terminal Total Difficulty Фиксированный порог накопленной сложности (TTD). Первый блок, чья суммарная сложность пересекает этот порог, — последний блок PoW; с этого момента голову определяет fork-choice beacon-цепочки. Поскольку порог основан на накопленной работе, его нельзя ни пропустить, ни подделать. (TTD). Первый блок, пересекающий этот порог, — последний блок, который когда-либо определяет майнинг. Начиная со следующего блока fork-choice beacon-цепочки (LMD-GHOST для головы, Casper FFG для финальности) выбирает каноническую цепочку. А ставшие бессмысленными поля заголовка proof of work нейтрализуются: difficulty и nonce обнуляются, список ommers/uncles очищается, старый слот mixHash переиспользуется, чтобы нести prevRandao (случайность beacon-цепочки), а награда за майнинг блока становится 0 — эмиссия целиком переходит на консенсус-слой.

TTD — линия накопленной работы: её нельзя ускорить или подделать total difficulty — каждый блок PoW прибавляет к ней TTD ✓ TTD пройден — майнинг останавливается, передача последний блок PoW difficulty → 0 первый блок PoS fork-choice beacon выбирает голову mixHash → prevRandao · nonce → 0 · reward → 0 та же цепь, то же состояние — меняется только выбор головы
При достижении Terminal Total Difficulty последний намайненный блок передаёт управление: с этого момента голову выбирает fork-choice beacon-цепочки. Рудиментарные поля заголовка PoW обнуляются — difficulty и nonce до 0, ommers очищаются, награда за блок до 0, — а mixHash переиспользуется, чтобы нести prevRandao.

→ Шаг 4: соединяем двигатель с водителем.

4 шаг Цикл Engine API

Слой исполнения становится двигателем, которым управляет консенсус-слой

После The Merge ваш узел — это на самом деле две программы: клиент консенсус-слоя (beacon-узел) и клиент слоя исполнения (старый Geth/Nethermind и т.д.), общающиеся через приватный, аутентифицированный Engine API Внутренний JSON-RPC интерфейс между клиентами консенсуса и исполнения. CL использует его, чтобы передать EL блоки на исполнение и сообщить, на какую голову ориентироваться; EL отвечает VALID или INVALID. Пользователи никогда не вызывают его напрямую. . Консенсус-слой рулит, слой исполнения исполняет. CL просит EL выполнить блок через engine_newPayload — EL исполняет транзакции, применяет переход состояния и отвечает VALID или INVALID — и использует engine_forkchoiceUpdated, чтобы задать каноническую голову и, когда этот валидатор — предлагающий, начать сборку следующей нагрузки. Затем CL аттестует и финализирует. EVM никогда не менялся — он просто получил нового начальника.

CL управляет EL через Engine API консенсус-слой предложить · аттестовать · финализировать слой исполнения выполнить и провалидировать engine_newPayload → execute & validate engine_forkchoiceUpdated → set head / build ← VALID, then the CL finalizes эмиссия и безопасность теперь от стейкинга, не майнинга
Консенсус-слой управляет слоем исполнения через Engine API: engine_newPayload просит EL исполнить и провалидировать блок (он отвечает VALID), engine_forkchoiceUpdated задаёт голову и запускает сборку. CL предлагает, аттестует и финализирует; EL просто исполняет EVM.
04 Глубже Куда двигаться дальше