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