Цю статтю зібрано та впорядковано BlockWeeks
Merge — це перехід Ethereum від консенсусу proof-of-work (PoW) до proof-of-stake (PoS), а також найскладніша та найрадикальніша зміна коду в історії Ethereum. Процес його активації відрізняється від будь-якого попереднього хардфорку: він складається з трьох основних кроків і вимагає від операторів вузлів переходу від запуску лише одного програмного клієнта до одночасного запуску двох клієнтів. Як найбільший у світі блокчейн загального призначення за ринковою капіталізацією та загальною заблокованою вартістю, Ethereum під час переходу ставить на карту величезні цінності та репутацію.
Що має вирішити Merge: злиття двох ланцюгів
Наразі транзакції Ethereum фіналізуються через протокол консенсусу PoW під назвою ethash. Паралельно з цим PoW-ланцюгом працює Beacon Chain — незалежний блокчейн, який з грудня 2020 року самостійно запускає новий протокол консенсусу PoS Ethereum під назвою Gasper.
Мета Merge — злити два ланцюги: змусити існуючий блокчейн Ethereum повністю покладатися на Beacon Chain для досягнення мережевого консенсусу та повністю відмовитися від proof-of-work. Ethereum, який ми знаємо сьогодні, більше не оброблятиме транзакції через ethash, а існуватиме лише як Execution Layer (EL), щоб децентралізовані застосунки та користувачі могли транслювати транзакції. Ethereum Virtual Machine (EVM), обчислювальний рушій Ethereum, продовжуватиме нормально працювати на Execution Layer.
Beacon Chain тоді стає Consensus Layer (CL) Ethereum: транзакції з Execution Layer отримуються, обробляються та фіналізуються тут. Пакування транзакцій Execution Layer у блоки та їх фіналізація через протокол Gasper стане обов'язком валідаторів Beacon Chain. Після Merge, щоб слідувати за головним ланцюгом Ethereum, усі валідатори та оператори повних вузлів повинні одночасно запускати два програмні клієнти — клієнт Execution Layer і клієнт Consensus Layer.
Крок перший: хардфорк Bellatrix
Спочатку Consensus Layer Ethereum виконує хардфорк під назвою Bellatrix. Bellatrix запроваджує нову структуру блоку Beacon Chain на Consensus Layer, щоб вміщувати блоки, які несуть транзакції Execution Layer. Він також вбудовує набір інструкцій, щоб вузли Consensus Layer не починали вставляти транзакції Execution Layer у блоки beacon, доки Execution Layer не досягне певної «Terminal Total Difficulty» (TTD). Усі вузли Consensus Layer повинні оновитися до Bellatrix до вказаної висоти слота (еквівалент висоти блоку в PoW-ланцюзі). Після завершення Bellatrix вузли Consensus Layer починають відстежувати TTD.
Ключове рішення: чому використовувати TTD, а не висоту блоку
Terminal Total Difficulty вимірює сукупну складність майнінгу Execution Layer Ethereum. Тут «складність» означає, наскільки важко майнерам додати новий блок до блокчейну, відображаючи, скільки комбінацій майнерам зазвичай потрібно спробувати, щоб знайти правильний хеш, який генерує наступний блок. У міру зростання обчислювальної потужності (хешрейту), яку надають майнери, складність автоматично зростає. TTD — це сума складності майнінгу всіх блоків в історії Ethereum.
Історично активація хардфорків Execution Layer ніколи не покладалася на конкретний TTD, а на попередньо встановлену висоту блоку. Merge відмовився від цього підходу через можливість атаки «швидкого форку»: зловмисник міг би використати меншість хешрейту, щоб форкнути Execution Layer і намайнити до вказаного номера блоку швидше, ніж головний ланцюг. Якби це сталося, Consensus Layer міг би помилково завершити злиття з ланцюгом меншості зловмисника, а не з головним ланцюгом. Тому розробники вирішили використовувати TTD як поріг для запуску Merge, оскільки зловмисникам набагато важче ним маніпулювати.
Але використання TTD як порогу також має свою ціну: TTD — це надзвичайно складне для прогнозування значення, що також робить прогнозування часу активації Merge після Bellatrix складним і неточним. Цей наслідок проявився, коли основні розробники вперше спробували активувати Merge у тестовій мережі Ropsten — початкове налаштування TTD було неточним, що спричинило відхилення часу активації від очікувань.
Крок другий і крок третій: Париж і перемикання рівня виконання
Коли рівень виконання досягає порогу TTD, запускаються дві пропозиції щодо оновлення рівня виконання, одна з яких — EIP-4399: вона змінює спосіб генерації ончейн-випадковості, більше не покладаючись на складність майнінгу для генерації випадкових цілих чисел для dApps. Обидва EIP активуються одночасно в момент досягнення TTD. У той самий час вузли рівня консенсусу, які чекали та відстежували це значення TTD, також починають обробляти транзакції з рівня виконання з цього моменту.
Темп випуску клієнтів і комунікація із зацікавленими сторонами повинні бути підкреслені. Для підготовки до хардфорку Bellatrix Фонд Ethereum, як очікується, опублікує допис у блозі за кілька тижнів до цього, перелічуючи версії клієнтів, що відповідають оновленням Париж і Bellatrix, щоб оператори вузлів могли завантажити їх заздалегідь. Ці початкові версії будуть заповнені надзвичайно великим значенням TTD як заповнювачем. Оскільки Bellatrix активується на певній висоті слота, дата та орієнтовний час цього оновлення також будуть повідомлені відповідним сторонам.
Після завершення Bellatrix нове значення TTD буде знову повідомлено операторам вузлів через другий допис у блозі. Цього разу повне оновлення клієнтів рівня консенсусу або рівня виконання не потрібне; як мінімум, до кожного з двох типів клієнтів потрібно додати лише один рядок коду, щоб вручну перевизначити попереднє значення TTD. Необов'язкові оновлення клієнтів також можуть бути запропоновані в цей час, але це рішення кожної команди клієнта і аж ніяк не обов'язковий випуск, необхідний для проходження фінальної стадії Злиття.
Після оголошення перевизначеного значення TTD починається етап очікування досягнення нового порогу. Хоча будуть приблизні оцінки часу, точну дату та час активації Парижа неможливо заздалегідь точно знати.
Ризики виконання, які не можна ігнорувати
1. Операційний вакуум, спричинений непередбачуваністю часу
Неможливість точно передбачити TTD означає, що всі сервіси, які покладаються на Ethereum, не можуть заздалегідь зафіксувати точний час "моменту Злиття". Для бізнесів, яким потрібно призупинити або заморозити депозити та зняття коштів, це становить реальний операційний виклик.
2. Операційний тиск архітектури з двома клієнтами
Після Злиття оператори вузлів повинні одночасно запускати клієнти рівня виконання та рівня консенсусу, і будь-яка неправильна конфігурація або невідповідність версій на будь-якій стороні може призвести до відставання вузла. Тому ранні репетиції в тестових мережах (Sepolia, Goerli) стають вирішальними.
3. Фундаментальна зміна логіки виробництва блоків і фіналізації
Після Злиття блоки більше не будуть фіналізуватися в одиницях висоти блоку, а в одиницях слотів і епох. Валідатори обробляють один слот кожні 12 секунд, і 32 слоти складають одну епоху, тобто одна епоха кожні 6,4 хвилини. Транзакції в Beacon Chain досягають фіналізації після 2 епох, приблизно 12,8 хвилини. Для бірж, DEX та інших DeFi-додатків, побудованих на різних припущеннях щодо фіналізації транзакцій і швидкості підтвердження, ці майбутні зміни необхідно передбачити та підготуватися до них заздалегідь, щоб уникнути перебоїв у обслуговуванні або експлуатації.
Висновок: мала ймовірність, великий вплив
Перехід Ethereum від PoW до PoS є найбільш пильно відстежуваним і найбільш далекосяжним оновленням блокчейну рівня 1 в історії криптовалют; ніколи раніше мережа, порівнянна за масштабом і важливістю з Ethereum, не зазнавала таких кардинальних змін. Оскільки розробники вклали величезні зусилля в тестування та підготовку, ймовірність того, що вищезазначені ризики серйозно вплинуть на користувачів і dApps, невисока; але якщо будь-який із описаних у цій статті сценаріїв станеться настільки, що мережі потрібно буде відкотити оновлення через екстрений хардфорк, цінність і репутація Ethereum як блокчейну загального призначення можуть бути пошкоджені.
Тому всі зацікавлені сторони повинні чітко усвідомлювати ці ризики та вживати заходів для пом'якшення впливу потенційних проблем на їхнє власне використання мережі, наприклад, шляхом призупинення або заморожування депозитів і виведень коштів протягом критичних вікон, коли можуть виникати перебої. Водночас валідатори, dApps і постачальники послуг повинні підготуватися, беручи участь у подальших репетиціях активації в тестових мережах Sepolia та Goerli, що може як забезпечити опанування операторами вузлів найкращих практик щодо виконання оновлення Merge, так і виявити проблеми в процесі до активації в основній мережі. Крім того, пильність Ethereum Foundation, команд клієнтів і довірених медіа щодо дезінформації, пов'язаної з Merge, під час активації є особливо критичною — включаючи неправильні значення TTD, неправильні версії клієнтів, неправильні очікування щодо часу та неправильні операційні вказівки — і вони повинні швидко координуватися, щоб чітко інформувати відповідні сторони про те, до чого готуватися далі, доки оновлення Merge не буде повністю завершено.
