Віталік Бутерін пропонує міграцію бінарного дерева стану та перехід на RISC-V VM для підвищення ефективності протоколу

Засновник Ethereum Віталік Бутерін опублікував детальну технічну пропозицію, яка виступає за два основні оновлення протоколу: перехід від поточної шістнадцяткової дерева Меркла Патріша до бінарної структури стану та згодом заміна Віртуальної Машини Ethereum на архітектуру на базі RISC-V.

Пропозиції, викладені у пості березня 2026 року, спрямовані на вирішення вузьких місць у підтвердженні ефективності, зменшення вимог до пропускної здатності даних та покращення можливостей перевірки на стороні клієнта. Бутерін охарактеризував міграцію до бінарного дерева як “комплексне” оновлення, що включає десять років досвіду у проектуванні станового дерева, тоді як зміни у ВМ розглядає як довгостроковий план, який може зробити попередні компіли майже непотрібними та спростити архітектуру протоколу.

Пропозиція міграції до бінарного станового дерева для підвищення ефективності підтвердження

Бутерін описав EIP-7864, який наразі розробляється, і який замінить існуюче шістнадцяткове дерево keccak Merkle Patricia Tree Ethereum на бінарну структуру з більш ефективними хеш-функціями. Запропонована зміна зменшить довжину гілки Меркла у чотири рази, з 512*log(n)/4 до 32*log(n) байт.

Це зменшення знизить вимоги до пропускної здатності даних для інструментів перевірки на стороні клієнта, таких як Helios та системи приватного отримання інформації. Ефективність підтвердження зросте у три-чотири рази лише за рахунок коротших гілок, а додаткові вигоди можна отримати за рахунок вибору хеш-функцій. Потенційні кандидати на хеш-функції включають blake3, що забезпечує приблизно тричі більшу ефективність порівняно з keccak, або варіанти Poseidon, які можуть дати 100-кратне підвищення ефективності за умови додаткового аналізу безпеки.

Бінарний дизайн дерева включає групування “сторінок”, що об’єднує сусідні слоти зберігання у сторінки від 64 до 256 слотів, що становить від 2 до 8 кілобайт даних. Ця структура дозволяє отримати подібні переваги у доступі до зберігання, як і при завантаженні та редагуванні коду. Заголовки блоків і перші приблизно 1-4 кілобайти коду та зберігання будуть розміщені у тій самій сторінці, що потенційно заощадить понад 10 000 газів за транзакцію для децентралізованих додатків, які часто звертаються до початкових слотів зберігання.

Додаткові переваги включають зменшення варіацій у глибині доступу між великими та малими контрактами, простішу реалізацію порівняно з шістнадцятковими структурами та можливість додавання метаданих, необхідних для майбутніх реалізацій терміну дії стану.

Розгляд переходу Віртуальної Машини на архітектуру RISC-V

Бутерін представив аргументи на користь заміни Віртуальної Машини Ethereum на архітектуру на базі RISC-V, описуючи EVM як обмежену у задоволенні потреб загального призначення Ethereum. Пропозиція визначає кілька цілей щодо підвищення ефективності нової ВМ.

Покращення швидкості виконання може усунути більшість вимог до попередніх компіляцій. Ефективність доказів зросте, що вирішить поточні обмеження, коли провери пишуться для RISC-V, а не для EVM. Можливості підтвердження на стороні клієнта дозволять користувачам генерувати ZK-докази щодо поведінки облікових записів за певних умов даних. Простота реалізації досягатиметься за рахунок інтерпретатора RISC-V, який потребує лише кілька сотень рядків коду.

Був окреслений трьохетапний план розгортання. Перший етап обмежить нову ВМ функціями попередніх компіляцій, з приблизно 80 відсотками існуючих та нових, реалізованих як код NewVM. Другий етап дозволить користувачам розгортати контракти на базі NewVM. Третій етап повністю зніме підтримку EVM, переписавши її як смарт-контракт, написаний у новій ВМ.

Користувачі EVM збережуть повну зворотну сумісність під час цього переходу, причому зміни у вартості газу будуть основною різницею, хоча Бутерін зазначив, що ці зміни будуть переважати над поточними роботами з масштабування у наступні роки.

Контекст еволюції протоколу та розгляд розробників

Бутерін охарактеризував обидва пропозиції як рішення найбільших вузьких місць у ефективності підтвердження, які разом становлять понад 80 відсотків навантаження на підтвердження. Зміни описуються як обов’язкові для різних сценаріїв підтвердження на стороні клієнта.

Міграція до бінарного дерева розглядається як врахування досвіду десяти років у проектуванні станового дерева. Перехід на нову ВМ позиціонується як більш спекулятивний і наразі не консенсусний, оскільки Бутерін зазначив, що Ethereum залишатиметься функціональним лише з EVM і покращеннями GPU, але краща ВМ могла б зробити протокол “гарним і чудовим”.

Обидва пропозиції мають строки реалізації, що відповідають довгостроковому плану стану Ethereum: міграція до бінарного дерева проходить через процес EIP, а перехід на нову ВМ вважається довгостроковою ініціативою, яка залежить від завершення змін у становому дереві.

FAQ: Пропозиції оновлення протоколу Ethereum

У чому різниця між поточним станом дерева Ethereum і запропонованим бінарним деревом?

Ethereum наразі використовує шістнадцяткове дерево keccak Merkle Patricia Tree з хешуванням keccak. Запропоноване бінарне дерево використовуватиме бінарну структуру з більш ефективними хеш-функціями, зменшуючи довжину гілки Меркла приблизно у чотири рази. Це зменшить пропускну здатність даних для перевірки на стороні клієнта та покращить ефективність підтвердження. Бінарний дизайн також групує слоти зберігання у сторінки для більш ефективного доступу.

Як перехід від EVM до RISC-V вплине на існуючі додатки Ethereum?

За трьохетапним планом, існуючі додатки на EVM збережуть повну зворотну сумісність під час переходу. EVM згодом буде переписана як смарт-контракт, написаний у новій ВМ, що дозволить продовжувати функціонування існуючих контрактів. Вартість газу зміниться, але ці зміни будуть супроводжуватися іншими покращеннями масштабування.

Які покращення ефективності може надати нова ВМ?

RISC-V-архітектура може запропонувати таку швидкість виконання, що зможе усунути більшість вимог до попередніх компіляцій, покращену ефективність провірки порівняно з поточним EVM, а також можливості підтвердження на стороні клієнта для створення ZK-доказів щодо поведінки облікових записів. Реалізація буде значно простішою, з інтерпретатором, що потребує лише кілька сотень рядків коду, порівняно з поточною складністю EVM.