The Merge: как Ethereum сменил механизм консенсуса
В сентябре 2022 года Ethereum сменил proof of work на proof of stake без остановки основной сети. Разбираем роль Beacon Chain, подготовку клиентов, сам триггер перехода и то, чего The Merge не менял.
В середине сентября 2022 года у Ethereum закончилась эпоха майнинга. Изменение не требовало от владельцев ETH нажать кнопку или перейти на новый адрес. При этом операторы узлов должны были подготовить сразу два типа программного обеспечения, а сама сеть переключилась с одного способа согласования блоков на другой, не выключаясь на длительное обслуживание. Это и было The Merge — редкий пример замены двигателя у движущегося поезда.
Название звучит как объединение двух блокчейнов, но история сложнее. Существующая сеть Ethereum уже исполняла транзакции и смарт-контракты. Beacon Chain — отдельная цепь консенсуса proof of stake — работала с декабря 2020 года. The Merge связал исполнительный слой Ethereum с консенсусным слоем Beacon Chain. Чтобы понять масштаб перехода, полезно разделить подготовку, момент переключения и свойства, которые действительно изменились.
Содержание
- Зачем менять механизм консенсуса
- Beacon Chain как испытательная площадка
- Клиенты, тесты и распределённая подготовка
- Как сеть переключилась
- Что изменилось в работе Ethereum
- Чего The Merge не обещал
Зачем менять механизм консенсуса
До The Merge Ethereum mainnet использовал proof of work. Майнеры собирали транзакции и конкурировали за право предложить следующий блок, затрачивая вычисления и электроэнергию. Proof of work связывает производство блоков с реальными затратами на оборудование и энергию. Этот механизм широко известен по раннему Bitcoin, но он не единственный способ сети договориться о порядке транзакций.
В proof of stake участники вносят ETH в стейкинг и запускают валидаторское программное обеспечение. Валидаторы предлагают блоки и подтверждают работу других участников. Правила назначают их на конкретные обязанности, а экономические санкции должны сделать нарушение протокола невыгодным. Такой механизм требует иных предпосылок: сеть опирается на заложенный капитал и корректную работу валидаторов, а не на гонку хеширования.
Это не означает, что одна схема автоматически «безопаснее» другой. Proof of work делает атаку затратной через вычисления и энергию; proof of stake — через заложенный капитал и правила, которые могут штрафовать недобросовестное поведение. В обоих случаях устойчивость зависит от того, насколько широко распределены ресурсы и участники, как устроены стимулы и как сеть переживает ошибки программ и координации. Поэтому переход был спором об инженерной и экономической модели, а не простой заменой дорогого оборудования на дешёвое.
Переход Ethereum обсуждался задолго до 2022 года. В дорожной карте это был не косметический апдейт, а изменение того, как сеть выбирает и закрепляет блоки. У такого решения были технические мотивы, в том числе снижение энергозатрат и изменение модели безопасности. Но реальная миграция должна была решить инженерную задачу: подключить новый консенсус к уже работающему исполнению транзакций, не создать две конкурирующие версии истории и дать операторам время подготовиться.

Beacon Chain как испытательная площадка
Beacon Chain запустилась в декабре 2020 года как отдельная сеть proof of stake. Она не заменяла mainnet и не исполняла его обычные пользовательские контракты. Её задача состояла в том, чтобы запустить валидаторский консенсус и наработать историю работы до подключения к Ethereum execution layer. Отдельная работающая цепь позволяла тестировать правила, клиентов и поведение валидаторов в реальной сети, прежде чем сделать её источником консенсуса для mainnet.
Валидаторский слой имел собственный ритм. Он делил время на слоты и эпохи, назначал валидаторов на предложения и аттестации и постепенно закреплял историю блоков через финализацию. Если часть участников пропускала обязанности, сеть могла продолжать работу при достаточном числе активных участников, но темп и финальность зависели от того, кто онлайн. Beacon Chain была действующим экспериментом с экономическими ставками, а не одноразовой демонстрацией в тестовом окружении.
Такое устройство можно сравнить с запуском нового диспетчерского центра рядом с действующей железной дорогой. Пока старый центр управлял поездами, новый отрабатывал правила расписания и связи. Сам Merge состоял в согласованном переходе на новые правила: Beacon Chain стала консенсусным слоем, а прежний execution layer продолжил обрабатывать транзакции и состояние аккаунтов.
Эта метафора имеет пределы: в сети нет единого диспетчера, который мог бы самовольно объявить переход. Правила были реализованы в программном обеспечении, а операторы должны были обновить узлы. EIP-3675 описал консенсусные изменения, а связанные спецификации уточняли взаимодействие слоёв. Запущенная заранее Beacon Chain давала будущему консенсусу историю и участников, но не устраняла сложность совместимости.

Клиенты, тесты и распределённая подготовка
Узел после перехода должен был согласовать два разных вида работы. Execution client проверяет транзакции, исполняет смарт-контракты и ведёт состояние аккаунтов. Consensus client участвует в Beacon Chain и отвечает за proof of stake. До Merge оператору proof-of-work-узла достаточно было execution client для работы основной сети. После переключения узлам Ethereum требовалась пара клиентов, соединённых через Engine API.
Это разделение повышало гибкость разработки, но усложняло обновление. Оператор должен был установить совместимые версии обоих клиентов, настроить их связь и следить за предупреждениями команд. Для валидатора требования были ещё выше: ему нужно было корректно выполнять обязанности в консенсусе, а также иметь связанный execution client, чтобы проверять транзакции и строить блоки. Пользователь, который просто хранил ETH или отправлял транзакции через биржу, отдельную миграцию кошелька проводить не должен был.
Подготовка была распределённой: команды разных клиентов выпускали версии, тестовые сети проходили собственные переходы, разработчики проверяли взаимодействие компонентов, а участники инфраструктуры отслеживали готовность. В августе 2022 года Ethereum Foundation объявила двухэтапную последовательность: Bellatrix на Beacon Chain, затем Paris на execution layer, когда сеть достигнет Terminal Total Difficulty. Это значение сложности служило триггером, привязанным к работе proof-of-work-цепи, а не заранее выбранному номеру календарного блока.
В объявлении 24 августа были перечислены совместимые версии execution- и consensus-клиентов. Это важно для истории: обновление было не только правилом в документе. Реальные узлы должны были запускать взаимно совместимые реализации, чтобы получать транзакции, проверять блоки и сообщать о состоянии сети. Разные команды реализуют одну спецификацию независимо, что помогает избежать полной зависимости от одного клиента, но требует тщательного тестирования комбинаций.
Тестирование не означало отсутствия риска. Узлы могли использовать разные клиенты, оборудование и конфигурации. Ошибка в одном компоненте могла привести к задержке финализации или рассогласованию. Поэтому обновление не пытались наполнить несвязанными изменениями: объявление Ethereum Foundation подчёркивало, что Merge сосредоточен на переходе механизма консенсуса.

Как сеть переключилась
Переход провели в два этапа. Bellatrix активировалась на Beacon Chain в заданную эпоху и подготовила консенсусный слой к Merge. Paris запускался, когда proof-of-work-цепь достигла Terminal Total Difficulty, или TTD. Значение TTD было зафиксировано для mainnet, но точный момент зависел от скорости накопления сложности, то есть в том числе от текущего хешрейта майнинга.
После достижения порога следующий блок должен был быть предложен уже валидатором Beacon Chain. В объявлении Ethereum Foundation сеть считалась перешедшей после того, как Beacon Chain финализировала этот блок. Так старый механизм довёл цепь до заранее согласованного условия, а новый продолжил её под правилами proof of stake. Переход состоялся 15 сентября 2022 года; эту дату позже подтвердили участники инфраструктуры, включая Circle в сообщении о работе USDC после апгрейда.
Условие по TTD было выбрано потому, что майнинговая цепь создаёт блоки с переменным интервалом. Назначить точный номер последнего proof-of-work-блока заранее было бы менее надёжно: скорость достижения порога менялась бы вместе с хешрейтом. В августе команда сообщала прогнозное окно и предупреждала, что оно может сместиться. Эта разница между календарной оценкой и протокольным триггером — часть инженерной истории перехода.
Фраза «объединили два блокчейна» полезна как короткое название, но скрывает, что именно сохранилось. Аккаунты, контракты, балансы и история транзакций Ethereum не были заново созданы в Beacon Chain. Изменился источник консенсуса и способ, которым блоки получали подтверждения. Поэтому приложения продолжили работать на той же исполнительной среде, хотя операторам узлов потребовалась новая связка программ.

Что изменилось в работе Ethereum
Самым известным последствием стало резкое сокращение энергопотребления, потому что участникам больше не требовалось конкурировать в вычислительном майнинге Ethereum. До события Ethereum Foundation публиковала оценку снижения примерно на 99,95%, основанную на предположениях о числе и конфигурациях валидаторских серверов. Это была оценка, а не прямое измерение будущего результата. Важно сохранять такую атрибуцию: процент зависел от модели энергопотребления и не означал, что сеть стала расходовать ноль энергии.
Изменился и способ выбора блока. Вместо майнеров, соревнующихся за proof of work, в консенсусе участвовали валидаторы Beacon Chain. У proof of stake появились слоты, эпохи и финализация, понятия, отличные от ожидания нескольких подтверждений в майнинговой цепи. Это изменило работу операторов и предоставило приложениям новые сигналы о состоянии блоков, но не сделало откат или сбой логически невозможным.
Техническая граница между слоями стала более заметной. Исполнение транзакций не исчезло и не переехало целиком в Beacon Chain. Execution layer сохранил виртуальную машину и обработку транзакций, а consensus layer координировал выбор и подтверждение блоков. Чтобы сеть оставалась устойчивой, операторы должны были корректно поддерживать оба клиента и их взаимодействие.
Появилась и новая терминология для приложений: наряду с привычной «головой» цепи появились safe head и finalized head. Они помогают приложениям рассуждать о степени закрепления блока в proof-of-stake-механизме. Однако разработчики должны были понимать, что эти метки означают и как обрабатывать ситуацию, когда узел отстаёт или не может связаться с клиентом другого слоя. Слово «финализирован» не заменяет корректную интеграцию и проверку предположений приложения.

Чего The Merge не обещал
Merge не был обещанием, что комиссии немедленно станут низкими. Стоимость транзакции зависела от спроса на включение операций и ограничений пропускной способности блока. Смена консенсуса сама по себе не расширяла исполнительные ресурсы настолько, чтобы убрать конкуренцию за место. Ethereum Foundation отдельно предупреждала, что The Merge не должен восприниматься как повышение производительности, заметное пользователю.
По той же причине Merge не гарантировал мгновенное ускорение блоков. Средний интервал изменился умеренно: в proof of stake слоты были привязаны к расписанию, но пропуски валидаторов могли задерживать включение. Это не то же самое, что кратно увеличить количество транзакций, которые сеть способна обработать. Пользователь мог увидеть те же приложения и прежний рынок комиссий, хотя за кулисами изменился способ построения и подтверждения блоков.
Отдельно стоит различать обещание будущей выгоды и функцию завершённого апгрейда. Обновление делало возможными следующие шаги в развитии протокола, но само не добавляло шардирование, не отменяло ограничение размера блока и не превращало стейкинг в банковский депозит с гарантированной доходностью. В публикациях Foundation до перехода эти границы формулировались явно. Именно такой минимальный масштаб и помогал снизить риск: в сложное обновление включали лишь изменения, необходимые для смены консенсуса.
Это также не было завершением масштабирования Ethereum и не включало все функции, когда-либо обсуждавшиеся в дорожной карте. В частности, вывод застейканного ETH не был частью перехода: в августе 2022 года Foundation говорила о нём как о будущем обновлении. Позднее выводы добавили отдельным апгрейдом Shanghai/Capella в 2023 году. Этот факт подтверждает границу Merge, а не означает, что остальные улучшения автоматически последовали в тот же день.
Наконец, proof of stake не устраняет экономические и управленческие вопросы. Нужно по-прежнему изучать концентрацию валидаторов, роль пулов и провайдеров, риски программных ошибок и стимулы участников. Уменьшение энергозатрат — важное свойство перехода, но оно не отвечает на все вопросы о децентрализации и безопасности. The Merge был одной крупной заменой в работающей системе; его достоинства и ограничения оцениваются по тем свойствам, которые он действительно изменил.
История этого обновления — не только рассказ о переключении алгоритма. Это пример того, как протокол может готовить новую часть архитектуры годами, проверять её отдельно, согласовать множество независимых клиентов и провести переход через формализованный триггер. Успех виден в непрерывности сети, но непрерывность не делает процесс простым: она была результатом спецификаций, тестов и координации большого числа операторов.
Источники
- EIP-3675: Upgrade consensus to Proof-of-Stake, создан 22 июля 2021.
- Ethereum Foundation, Mainnet Merge Announcement, 24 августа 2022.
- Ethereum Foundation, Finalized no. 36, 12 августа 2022.
- Ethereum Foundation, Ethereum’s energy usage will soon decrease by ~99.95%, 18 мая 2021; оценка, не измеренный итог.
- Ethereum Foundation, How The Merge Impacts Ethereum’s Application Layer, 29 ноября 2021.
- Ethereum Foundation, The State of Eth2, Jan 2021, 20 января 2021.
- Circle, The Merge & USDC: By the Numbers, 20 сентября 2022; источник участника инфраструктуры для даты завершения.
Также читайте
Технологические пузыри: железные дороги, доткомы и крипторынок
Железные дороги, интернет и криптовалюты показывают, как реальная инновация может соседствовать с переоценёнными инвестициями. История помогает разделять пользу инфраструктуры, устойчивость проекта и доходность актива.
Аппаратные кошельки: как инженеры защищают секрет
Аппаратный кошелёк может изолировать закрытый ключ от компьютера, но не отменяет риск подмены транзакции, прошивки, резервной копии или ошибки пользователя. Разбираем, как модель угроз определяет устройство и пределы его защиты.
FTX: как смешение биржи и торгового бизнеса разрушило доверие
Торговая активность FTX не гарантировала, что клиентские средства доступны для вывода. История связи биржи с Alameda показывает, почему важно различать котировки, ликвидность и право собственности на активы.
Ник Сабо: смарт-контракты до появления Ethereum
Ник Сабо называл смарт-контрактом не только программу в блокчейне, а протокол, который исполняет часть условий сделки. Торговый автомат, цифровая собственность и bit gold показывают широту идеи и её пределы.
Новая игра на понижение: почему Бьюрри шортит полупроводники
Что прогнозирует Бьюрри, который предсказал крах 2008?
Terra и UST: история механизма, который потерял равновесие
UST обещал держаться у доллара благодаря обмену с токеном LUNA. История краха Terra показывает, как механизм стабилизации стал петлёй обратной связи, а высокая доходность Anchor усилила уязвимость системы.

Комментарии