Шлях Ethereum 2026: Виклики валідаторів, які ви недооцінюєте

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

Два стовпи масштабування

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

Перший шлях вже має конкретну опору у вигляді Fusaka, розгортання якого відбулося 3 грудня 2025 року. Це оновлення вводить PeerDAS разом із коригуваннями параметра блобів (BPO), що дозволяє поступове підвищення продуктивності без необхідності завантажувати всі дані блобів кожним вузлом. За керівництвом ethereum.org, цілі щодо блобів не досягаються одразу після активації, а можуть подвоюватися кожні кілька тижнів до максимуму 48 блобів за блок, при цьому за станом мережі слідкують.

Команда Optimism прогнозує у своєму оптимістичному сценарії “щонайменше 48 цільових блобів”, що означає збільшення продуктивності rollup з приблизно 220 до близько 3,500 UOPS. Але тут виникає перша невизначеність: чи справді зросте попит на використання блобів, чи продовжать зростати конкуренційні ставки за виконання в L1?

Невідомі інфраструктури

Стабільність peer-to-peer та пропускна здатність вузлів є реальними викликами при зростанні BPO. GasLimit.pics повідомляє про поточний граничний газ у 60 000 000, з середнім за 24 години у 59 990 755 у момент спостереження. Це число слугує орієнтиром для того, що валідатори вже прийняли на практиці, але також обмежує “соціальне масштабування” до того, як латентність, навантаження на валідацію та тиск у mempool стануть обмежувальними.

Щоб швидко переводити дискусію про граничний газ у швидкість транзакцій, потрібно враховувати інтервал у 12 секунд Ethereum. За поточної координації продуктивність становить приблизно 238 транзакцій за секунду (a 21k gas) або 42 (a 120k gas). Сценарій подвоєння збільшить ці значення до 476 і 83 відповідно, тоді як найвищі рівні (з необхідністю змін у валідації) досягнуть 793 і 139 транзакцій/сек.

Glamsterdam: прихована складність

Заплановане на 2026 рік оновлення об’єднує ініціативи, орієнтовані на виконання, під назвою “Glamsterdam”, що включає розділення пропонента та конструктора (ePBS, EIP-7732), списки доступу на рівні блоку (BALs, EIP-7928) та загальну переоцінку газу (EIP-7904). Всі вони залишаються у вигляді чернеток.

Переоцінка газу має на меті виправити накопичені роками дисбаланси у тарифній схемі. EIP-7904 стверджує, що виправлення помилок обчислень може збільшити корисну продуктивність, хоча й визнає ризики DoS та реальність контрактів, що закодовані з урахуванням конкретних припущень щодо газу.

BALs позиціонуються як інфраструктура для справжнього паралелізму. У EIP згадуються паралельне зчитування з диска, одночасна валідація транзакцій та паралельне обчислення кореня стану, з приблизною додатковою навантаженняю у 70-72 КиБ у стисненому вигляді на один BAL. Але ці теоретичні вигоди реалізуються лише за умови, що клієнти впровадять конкуренцію у вузьких місцях справжнього обмеження.

ePBS є предметом обговорень, оскільки він тимчасово відокремлює валідацію виконання від валідації консенсусу, відкриваючи вікна для нових режимів збоїв. Наукові дослідження щодо “проблеми безкоштовних опціонів” оцінюють виконання опціонів у середньому 0,82% блоків за вікно у 8 секунд, зростаючи до 6% під час екстремальної волатильності за аналізами на arXiv.

Роль ZK Proofs у дорожній карті

Найбільш структурована ставка щодо значно більшого граничного газу базується на впровадженні доказів виконання ZK. Дорожня карта “Realtime Proving” Фонду Ethereum описує поступове розгортання: спершу невелика група валідаторів запускає клієнти ZK у виробництві, потім, коли більшість стейку почуватиметься комфортно, граничний газ може зростати до рівнів, де перевірка доказів замінить повторне виконання.

Технічні обмеження важливіші за наратив: ціль безпеки — 128 біт (100 біт тимчасово прийняті), розмір доказу менше 300 КиБ, та уникнення залежності від рекурсивних обгорток із надійними налаштуваннями. Масштабованість, що виникне, буде залежати від ринків тестування: пропозиція має бути дешевою та надійною без концентрації унікальних тестувальників, що відтворюють залежності типу relay у іншому шарі стеку.

Hegota та критичний графік

“Hegota” позиціонується як тимчасова рамка наприкінці 2026 року, більше зосереджена на процесі, ніж на остаточному обсязі. Ethereum Foundation встановила вікно основних пропозицій з 8 січня по 4 лютого, обговорення — з 5 по 26 лютого, потім — вікно для вторинних пропозицій.

Мета-EIP Hegota (EIP-8081) перераховує елементи як “розглядаються”, а не “затверджені”, включаючи FOCIL (EIP-7805). Реальна цінність у короткостроковій перспективі полягає у тому, що він створює точки прийняття рішень із конкретною датою, яку інвестори та розробники можуть відслідковувати без необхідності робити висновки щодо імен у ключах.

Перший критичний етап — закриття основних пропозицій Hegota 4 лютого. Це дає змогу мати ясність щодо того, які елементи дорожньої карти Ethereum до 2026 року дійсно перейдуть до реалізації, а які залишаться у сфері спекулятивних обговорень.

Чого повинні очікувати валідатори

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

Головне питання, яке ставить дорожня карта Ethereum до 2026 року для операторів інфраструктури, — чи готові вони інвестувати у нове апаратне та програмне забезпечення для функціональності, яка може бути відкладена або не знайде широкого впровадження, якщо реальний ринок відрізнятиметься від технічних прогнозів.