27 лютого 2026 року Віталік Бутерин опублікував довгу статтю під назвою «Гіпермасштабування стану шляхом створення нових форм держави» на Ethereum Research.
У цій статті Віталік Бутерін детальніше розглядає шляхи розширення Ethereum. Ця стаття не лише розглядає розширення Ethereum з технічної точки зору, а й пропонує набір поетапних планів розширення з загальної архітектурної точки зору, які мають на меті створити основу для подальшого розширення мережевої потужності Ethereum у найближчі роки.
Водночас він також опублікував твіт на X, щоб детальніше пояснити статтю. Ми намагалися зрозуміти, який новий план розширення Vitalik і чому він це робить.
Короткострокове та довгострокове розширення керівних ресурсів і ресурсів даних
Віталік розпочав свою довгу статтю з того, що «щоб масштабувати Ethereum у наступні п’ять років, потрібно масштабувати три ресурси»:
Ресурси виконання: обчислення EVM, верифікація підписів тощо
Ресурси даних: відправник, отримувач, підпис тощо транзакції
Державні ресурси: баланс рахунку, код, зберігання
Перші два мають короткострокові та довгострокові плани розширення.
Для ресурсів виконання, короткострокового зростання близько 10-30x через списки доступу до блоків (BALS), ePBS та переоцінку тарифів за газ, довгострокове зростання близько 1000 разів через ZK-EVM, а також для деяких специфічних типів обчислень (сигнатури, SNARK/STARK) агрегування поза ланцюгом може підвищити продуктивність приблизно у 10 000 разів.
Щодо ресурсів даних, покращення P2P і багатовимірний газ можуть досягти приблизно 10-20 разів зростання в короткостроковій перспективі та приблизно у 500 разів зростання завдяки Blobs + PeerDAS у довгостроковій.
Короткострокове розширення спрямоване на те, щоб Ethereum працював швидше. Ethereum зараз повільний, оскільки поточний метод верифікації — це серійний — перевірка транзакцій одна за одною. Якщо транзакція застрягає, весь процес верифікації застрягає.
Тому цьогорічне оновлення Гламстердаму запустить Block Access List (BAL) та ePBS.
Список блокового доступу дозволяє пакувальнику блоків заздалегідь повідомити валідатора, що транзакції в цьому блоці отримуватимуть доступ до цих рахунків і сховищ. З цією інформацією валідатор може заздалегідь підготуватися до завантаження цих даних з жорсткого диска в пам’ять. Валідатори можуть перевіряти кілька транзакцій паралельно, а не перевіряти їх по одній. Це як конвеєр на заводі: раніше працівник відповідав за весь продукт, а тепер кілька працівників одночасно працюють над різними деталями.
ePBS розділяє процеси пакування та валідації блоків — конструктори блоків відповідають за транзакції пакування, пропонувачі — за пропозиції блоків, а валідатори — за верифікацію блоків. Кожна роль виконує свою частину своєї роботи, тож конструктор блоків може більш агресивно пакувати більше транзакцій, адже пропонатор і валідатор перевірятимуть за нього, не турбуючись про безпеку.
Переоцінка тарифів за газ + багатовимірний газ можна назвати «рухом ядра». Тепер усі операції на Ethereum використовують однакову газову плату. Але ідея Віталіка полягає в тому, що різні підприємства мають мати різні ціни.
Зокрема, має бути спеціальна «плата за створення штату» за створення нового штату (наприклад, створення нового акаунта, розгортання нового контракту). Адже створення нової держави — це найдорожча операція. Вона займає не лише обчислювальні ресурси, а й ресурси для зберігання. Більше того, ці витрати є постійними — після створення ця держава залишиться на місці.
Отже, ідея Віталіка така: зробити створення нової держави дорожчою, але зробити звичайні транзакції дешевшими.
Метод реалізації — це «механізм резервуара». Уявіть собі два відра: одне для «державної плати за створення стану», інше — для «звичайної газової плати». Коли контракти дзвонять один одного, газ автоматично позичає у двох бібліотек, щоб уникнути хаосу.
Транзакції для звичайних користувачів стануть дешевшими, оскільки їм не потрібно сплачувати «комісію за створення штату». Забудовники, які хочуть створити новий штат, повинні будуть платити вищу комісію. Таким чином, загальна пропускна здатність мережі різко зростає, але зростання стану контролюється, і жорсткі диски всіх вузлів не вибухнуть.
Довгострокове розширення — це зробити основну мережу більшою та сильнішою, а також зменшити залежність від Layer 2. Це включає поетапне впровадження Blobs + PeerDAS проти ZK-EVM.
Blobs, тимчасове велике сховище файлів, тепер переважно використовуються Layer 2. У майбутньому сам основний мережа Ethereum також використовуватиме blobs для зберігання даних. Але виникає й проблема — якщо кожен вузол має завантажити всі блоки, мережа буде вибухнута.
Ось тут і з’являється PeerDAS — не потрібно завантажувати всі дані, лише невелику їх частину. Як і у вибірковому опитуванні, не потрібно питати всіх, достатньо попросити невелику групу людей, щоб зрозуміти ситуацію всієї групи. У поєднанні з доказами ZK ви можете підтвердити цілісність даних навіть якщо завантажено лише 1/16 від загальної кількості даних.
Далі йде поетапне впровадження ZK-EVM, яке усуває необхідність повторного виконання всіх транзакцій у блоці для верифікації блоку, і вузол може безпосередньо довіряти доказу ZK, знижуючи вартість перевірки з «виконання всіх транзакцій» до «перевірки доказу ZK».
План Віталіка — випробувати верифікацію ZK на деяких вузлах у 2026 році. До 2027 року більше вузлів заохочуватимуть його використовувати. Нарешті, щоб блок був дійсним, він повинен містити 3 із 5 типів доказів з різних систем доведення. Він очікує, що всі вузли (крім inodes) зрештою покладатимуться на докази ZK-EVM.
Немає «чарівної кулі» розширення стану
Тепер давайте розглянемо «державні ресурси», які не обговорювалися як у короткостроковій, так і в довгостроковій перспективі. Хоча в короткостроковій перспективі його все ще можна покращити приблизно у 5-30 разів завдяки синхронізації зі списками доступу до блоків, покращенням P2P та оптимізацією бази даних, але що ж у довгостроковій перспективі?
Відповідь Віталіка — ні.
Чому державні ресурси так важко масштабувати? Стан Ethereum — це як величезна база даних. Ця база даних містить баланс усіх рахунків, коди всіх контрактів та дані всіх місць зберігання.
База даних невелика, лише близько 100 ГБ, але якщо розширити стан у 20 разів, це буде 2 ТБ. А як щодо довшого часу? 8 ТБ?
Проблема не в тому, що жорсткий диск не підходить, а:
Ефективність бази даних впливає на це: сучасні бази даних використовують деревові структури, такі як дерева Меркла, для організації даних. Коли записуються нові дані, потрібно оновити все дерево. Це означає, що якщо ви хочете зробити X оновлень, ви виконаєте X операцій на рівні бази даних замість одного оновлення і однієї операції з базою даних. Чим більше оновлень і чим більше операцій, тим більше записів будуть повільними до вибуху.
Труднощі синхронізації: новий вузол, що приєднується до мережі Ethereum, повинен завантажити весь стан для перевірки нового блоку. Якщо масштаб даних сягає 8 терабайт, поточна швидкість інтернету у більшості людей буде значно нижчою.
Є рішення, але Віталік вважає, що є проблеми:
«Сильна безстанність»: вузлам не потрібно зберігати повний стан, потрібно лише надавати докази Меркла від користувачів. Віталік вважає, що це рішення має проблеми з централізацією зберігання стану, динамічним доступом до зберігання, що призводить до збоїв транзакцій, та витратами на пропускну здатність.
«Статус прострочений»: Рідко доступні статуси автоматично видаляються з активного статусу. Вузлам потрібно зберігати лише нещодавно отриманий стан, що може суттєво зменшити об’єм пам’яті. Віталік вважає, що існує фундаментальна «екзистенційна проблема» — як довести, що держава «ніколи не існувала», коли створюється нова держава. Припустимо, створено новий акаунт, тоді потрібно довести, що нова адреса ніколи не була створена в Ethereum. Це означає, що кожне створення нового рахунку вимагає перевірки 10 років історичних даних, що ускладнює і робить створення нового акаунта складним і дорогим.
Останній підхід Віталіка полягає в тому, щоб поєднати ці дві схеми та запропонувати кілька нових форм стану, які є повною зміною архітектури ресурсів стану Ethereum:
Тимчасове зберігання: тип сховища, який автоматично закінчується. Наприклад, ви можете створити нове дерево і автоматично очищати його щомісяця. Це сховище можна використовувати для тимчасових даних, таких як книги замовлень, пули ліквідності, тимчасові лічильники тощо, які зазвичай не потребують постійного зберігання, а через місяць старий ордер закінчується, і створюється новий пул ліквідності.
Періодичне зберігання: Схоже на тимчасове зберігання, але з більшим періодом, наприклад 1 рік.
Обмежене зберігання: До деяких сховищ можна отримати доступ лише певним чином. Наприклад, залишкове зберігання токена ERC20 може бути доступне лише через певний інтерфейс. Це дозволяє системі оптимізувати це зберігання.
Водночас зберігається існуюча форма держави. Таким чином, виконання може бути у 1000 разів дешевшим (через ZK-EVM), але створення нових станів може бути лише у 20 разів дешевшим.
Віталік вважає, що з новою формою держави у забудовників з’являються варіанти. Продовжуйте використовувати існуючу форму штату, але сплачуйте вищий внесок, або переробіть додаток і використайте нову форму штату за нижчу плату. Для поширених сценаріїв використання (наприклад, баланси ERC20, NFT) існують стандартизовані робочі процеси, а для більш складних сценаріїв (наприклад, DeFi) розробникам потрібно знаходити способи оптимізувати себе.
Ця стратегія досить цікава, і вона означає, що розробники використовують розум для зниження витрат, і більшість користувачів Ethereum отримують від неї вигоду.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Віталік визначає стратегію Ethereum на наступні п’ять років: підвищення ефективності виконання, розподіл даних, багаторівнева структура стану
27 лютого 2026 року Віталік Бутерин опублікував довгу статтю під назвою «Гіпермасштабування стану шляхом створення нових форм держави» на Ethereum Research.
У цій статті Віталік Бутерін детальніше розглядає шляхи розширення Ethereum. Ця стаття не лише розглядає розширення Ethereum з технічної точки зору, а й пропонує набір поетапних планів розширення з загальної архітектурної точки зору, які мають на меті створити основу для подальшого розширення мережевої потужності Ethereum у найближчі роки.
Водночас він також опублікував твіт на X, щоб детальніше пояснити статтю. Ми намагалися зрозуміти, який новий план розширення Vitalik і чому він це робить.
Короткострокове та довгострокове розширення керівних ресурсів і ресурсів даних
Віталік розпочав свою довгу статтю з того, що «щоб масштабувати Ethereum у наступні п’ять років, потрібно масштабувати три ресурси»:
Ресурси виконання: обчислення EVM, верифікація підписів тощо
Ресурси даних: відправник, отримувач, підпис тощо транзакції
Державні ресурси: баланс рахунку, код, зберігання
Перші два мають короткострокові та довгострокові плани розширення.
Для ресурсів виконання, короткострокового зростання близько 10-30x через списки доступу до блоків (BALS), ePBS та переоцінку тарифів за газ, довгострокове зростання близько 1000 разів через ZK-EVM, а також для деяких специфічних типів обчислень (сигнатури, SNARK/STARK) агрегування поза ланцюгом може підвищити продуктивність приблизно у 10 000 разів.
Щодо ресурсів даних, покращення P2P і багатовимірний газ можуть досягти приблизно 10-20 разів зростання в короткостроковій перспективі та приблизно у 500 разів зростання завдяки Blobs + PeerDAS у довгостроковій.
Короткострокове розширення спрямоване на те, щоб Ethereum працював швидше. Ethereum зараз повільний, оскільки поточний метод верифікації — це серійний — перевірка транзакцій одна за одною. Якщо транзакція застрягає, весь процес верифікації застрягає.
Тому цьогорічне оновлення Гламстердаму запустить Block Access List (BAL) та ePBS.
Список блокового доступу дозволяє пакувальнику блоків заздалегідь повідомити валідатора, що транзакції в цьому блоці отримуватимуть доступ до цих рахунків і сховищ. З цією інформацією валідатор може заздалегідь підготуватися до завантаження цих даних з жорсткого диска в пам’ять. Валідатори можуть перевіряти кілька транзакцій паралельно, а не перевіряти їх по одній. Це як конвеєр на заводі: раніше працівник відповідав за весь продукт, а тепер кілька працівників одночасно працюють над різними деталями.
ePBS розділяє процеси пакування та валідації блоків — конструктори блоків відповідають за транзакції пакування, пропонувачі — за пропозиції блоків, а валідатори — за верифікацію блоків. Кожна роль виконує свою частину своєї роботи, тож конструктор блоків може більш агресивно пакувати більше транзакцій, адже пропонатор і валідатор перевірятимуть за нього, не турбуючись про безпеку.
Переоцінка тарифів за газ + багатовимірний газ можна назвати «рухом ядра». Тепер усі операції на Ethereum використовують однакову газову плату. Але ідея Віталіка полягає в тому, що різні підприємства мають мати різні ціни.
Зокрема, має бути спеціальна «плата за створення штату» за створення нового штату (наприклад, створення нового акаунта, розгортання нового контракту). Адже створення нової держави — це найдорожча операція. Вона займає не лише обчислювальні ресурси, а й ресурси для зберігання. Більше того, ці витрати є постійними — після створення ця держава залишиться на місці.
Отже, ідея Віталіка така: зробити створення нової держави дорожчою, але зробити звичайні транзакції дешевшими.
Метод реалізації — це «механізм резервуара». Уявіть собі два відра: одне для «державної плати за створення стану», інше — для «звичайної газової плати». Коли контракти дзвонять один одного, газ автоматично позичає у двох бібліотек, щоб уникнути хаосу.
Транзакції для звичайних користувачів стануть дешевшими, оскільки їм не потрібно сплачувати «комісію за створення штату». Забудовники, які хочуть створити новий штат, повинні будуть платити вищу комісію. Таким чином, загальна пропускна здатність мережі різко зростає, але зростання стану контролюється, і жорсткі диски всіх вузлів не вибухнуть.
Довгострокове розширення — це зробити основну мережу більшою та сильнішою, а також зменшити залежність від Layer 2. Це включає поетапне впровадження Blobs + PeerDAS проти ZK-EVM.
Blobs, тимчасове велике сховище файлів, тепер переважно використовуються Layer 2. У майбутньому сам основний мережа Ethereum також використовуватиме blobs для зберігання даних. Але виникає й проблема — якщо кожен вузол має завантажити всі блоки, мережа буде вибухнута.
Ось тут і з’являється PeerDAS — не потрібно завантажувати всі дані, лише невелику їх частину. Як і у вибірковому опитуванні, не потрібно питати всіх, достатньо попросити невелику групу людей, щоб зрозуміти ситуацію всієї групи. У поєднанні з доказами ZK ви можете підтвердити цілісність даних навіть якщо завантажено лише 1/16 від загальної кількості даних.
Далі йде поетапне впровадження ZK-EVM, яке усуває необхідність повторного виконання всіх транзакцій у блоці для верифікації блоку, і вузол може безпосередньо довіряти доказу ZK, знижуючи вартість перевірки з «виконання всіх транзакцій» до «перевірки доказу ZK».
План Віталіка — випробувати верифікацію ZK на деяких вузлах у 2026 році. До 2027 року більше вузлів заохочуватимуть його використовувати. Нарешті, щоб блок був дійсним, він повинен містити 3 із 5 типів доказів з різних систем доведення. Він очікує, що всі вузли (крім inodes) зрештою покладатимуться на докази ZK-EVM.
Немає «чарівної кулі» розширення стану
Тепер давайте розглянемо «державні ресурси», які не обговорювалися як у короткостроковій, так і в довгостроковій перспективі. Хоча в короткостроковій перспективі його все ще можна покращити приблизно у 5-30 разів завдяки синхронізації зі списками доступу до блоків, покращенням P2P та оптимізацією бази даних, але що ж у довгостроковій перспективі?
Відповідь Віталіка — ні.
Чому державні ресурси так важко масштабувати? Стан Ethereum — це як величезна база даних. Ця база даних містить баланс усіх рахунків, коди всіх контрактів та дані всіх місць зберігання.
База даних невелика, лише близько 100 ГБ, але якщо розширити стан у 20 разів, це буде 2 ТБ. А як щодо довшого часу? 8 ТБ?
Проблема не в тому, що жорсткий диск не підходить, а:
Ефективність бази даних впливає на це: сучасні бази даних використовують деревові структури, такі як дерева Меркла, для організації даних. Коли записуються нові дані, потрібно оновити все дерево. Це означає, що якщо ви хочете зробити X оновлень, ви виконаєте X операцій на рівні бази даних замість одного оновлення і однієї операції з базою даних. Чим більше оновлень і чим більше операцій, тим більше записів будуть повільними до вибуху.
Труднощі синхронізації: новий вузол, що приєднується до мережі Ethereum, повинен завантажити весь стан для перевірки нового блоку. Якщо масштаб даних сягає 8 терабайт, поточна швидкість інтернету у більшості людей буде значно нижчою.
Є рішення, але Віталік вважає, що є проблеми:
«Сильна безстанність»: вузлам не потрібно зберігати повний стан, потрібно лише надавати докази Меркла від користувачів. Віталік вважає, що це рішення має проблеми з централізацією зберігання стану, динамічним доступом до зберігання, що призводить до збоїв транзакцій, та витратами на пропускну здатність.
«Статус прострочений»: Рідко доступні статуси автоматично видаляються з активного статусу. Вузлам потрібно зберігати лише нещодавно отриманий стан, що може суттєво зменшити об’єм пам’яті. Віталік вважає, що існує фундаментальна «екзистенційна проблема» — як довести, що держава «ніколи не існувала», коли створюється нова держава. Припустимо, створено новий акаунт, тоді потрібно довести, що нова адреса ніколи не була створена в Ethereum. Це означає, що кожне створення нового рахунку вимагає перевірки 10 років історичних даних, що ускладнює і робить створення нового акаунта складним і дорогим.
Останній підхід Віталіка полягає в тому, щоб поєднати ці дві схеми та запропонувати кілька нових форм стану, які є повною зміною архітектури ресурсів стану Ethereum:
Тимчасове зберігання: тип сховища, який автоматично закінчується. Наприклад, ви можете створити нове дерево і автоматично очищати його щомісяця. Це сховище можна використовувати для тимчасових даних, таких як книги замовлень, пули ліквідності, тимчасові лічильники тощо, які зазвичай не потребують постійного зберігання, а через місяць старий ордер закінчується, і створюється новий пул ліквідності.
Періодичне зберігання: Схоже на тимчасове зберігання, але з більшим періодом, наприклад 1 рік.
Обмежене зберігання: До деяких сховищ можна отримати доступ лише певним чином. Наприклад, залишкове зберігання токена ERC20 може бути доступне лише через певний інтерфейс. Це дозволяє системі оптимізувати це зберігання.
Водночас зберігається існуюча форма держави. Таким чином, виконання може бути у 1000 разів дешевшим (через ZK-EVM), але створення нових станів може бути лише у 20 разів дешевшим.
Віталік вважає, що з новою формою держави у забудовників з’являються варіанти. Продовжуйте використовувати існуючу форму штату, але сплачуйте вищий внесок, або переробіть додаток і використайте нову форму штату за нижчу плату. Для поширених сценаріїв використання (наприклад, баланси ERC20, NFT) існують стандартизовані робочі процеси, а для більш складних сценаріїв (наприклад, DeFi) розробникам потрібно знаходити способи оптимізувати себе.
Ця стратегія досить цікава, і вона означає, що розробники використовують розум для зниження витрат, і більшість користувачів Ethereum отримують від неї вигоду.