Наступний етап ethereum: з’єднання L1 і L2, підвищення конфіденційності та покращення UX

Якщо з’єднати оновлення Ethereum за останні кілька років лінією, ключовим словом без сумніву буде «масштабування».

Від введення Blob у Dencun, що значно знизило податки для Rollup, до налаштування ефективності валідаторів і механізму стейкінгу у Pectra, а потім до реалізації Fusaka з PeerDAS, що зменшує навантаження на розповсюдження даних, протокольний рівень майже повністю зосередився на одній речі: дозволити Ethereum обробляти більше даних, не піднімаючи надто високих бар’єрів для вузлів.

Цей комплекс заходів справді працює: витрати на дані Rollup знизилися, а ліміт Gas на основній мережі поступово зростає — ефір більше не вимагає десятків доларів за комісію, як у попередній бул-фазі.

Але коли дорогу розширили, все одно незручно їхати:

• Нам все ще потрібно переносити активи між трьома-чотирма L2, і досить легко помилитися й вивести на неправильний ланцюг;
• Одна транзакція очевидно була упакована за кілька секунд, але міст та біржі заставляють вас чекати понад десять хвилин, перш ніж підтвердити;
• Професійні Builder майже монополізували упаковку блоків; якщо ви хочете відправити чутливу транзакцію, вона може бути відхиленою за межами протоколу через приховані правила;
• Тим паче, що до сьогодні новачок, який хоче просто перевести кілька сотень USDC, повинен спочатку зрозуміти, чому в гаманці має бути ETH, що таке Nonce і що таке Gas;

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

І саме це — нові проблеми, з якими почне стикатися Ethereum з концентрованою обробкою від Glamsterdam до Hegotá, з Q4 2026 року до 2027 року.

Звичайно, розширення не зупинить рух.

Glamsterdam зберігає сильний акцент на продуктивності, причому двома найбільш цікавими є ePBS (EIP-7732) та BAL (Block-level Access Lists, EIP-7928); у простих термінах:

• ePBS полягає у формалізації розподілу обов’язків між Proposer та Builder, які вже масово існують поза протоколом, а також більш науковому розподілі часових вікон для створення та перевірки блоків, щоб забезпечити достатній буфер для майбутнього збільшення розміру блоків;
• BAL еквівалентно включає список «доступу» на початку блоку, дозволяючи вузлам швидко отримати дані наперед або обробляти їх паралельно, що ефективно вирішує проблеми з I/O пам’яті;

Крім масштабування, сьогодні справжній болісний питання більшості людей — це не те, чи достатньо висока TPS Ethereum, а те, що «блокчейнів занадто багато».

Наприклад, ETH на основній мережі, меми, які грають на Robinhood Chain, USDC для платежів і розрахунків може бути на Arbitrum, а USDC, який ви хочете купити на дні — на Base.....

Для Фонда Етеріуму ролапи є частиною екосистеми Етеріуму, але для користувачів це не відрізняється від міжнародного обміну валюти або оформлення візи.

Тому, щоб знову з’єднати розсіяні шматочки пазлу в мережу, крім того, що міжланцюгові протоколи використовують різні методи, варто звернути увагу на новий базовий механізм, який недавно запроваджено на рівні протоколу — FCR (Fast Confirmation Rule, швидке правило підтвердження).

Багато людей вважають, що угоду вважають завершеною, як тільки її включено до блоку, але на рівні криптографії та консенсусу новий блок може зазнати невеликої перебудови. Справжня незворотність (Finality) на Ethereum вимагає проходження двох Epoch, що займає близько 13 хвилин.

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

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

Згідно з цілями, визначеними Фондом Ефіреуму, FCR має потенціал випередити цей «сильний підтвердження» до приблизно 15–30 секунд за умови нормального синхронізації мережі. Хоча це не еквівалентно повній фінальності, для багатьох мостів, міжмережевих комунікацій та інфраструктури, які зараз змушені чекати на фінальність, це вже достатньо, щоб надати раніший та чітко визначений сигнал підтвердження з безпечними моделями.

Ще більш специфічно, FCR не потребує чекання певного хардфорку для включення — він ближчий до набору правил підтвердження, які можуть бути поступово прийняті консенсусними клієнтами та інфраструктурою.

Коли різні L2, мостові з’єднання та гаманці почнуть використовувати цей сигнал, сьогоднішні значні затримки між рівнями, спричинені «очікуванням фінальності L1», можуть бути скорочені з кількох хвилин до декількох десятків секунд.

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

Однак, коли блоки стають все більшими, а Builder — все більш професійними, Ethereum знову стикається з іншою дуже типовою дилемою.

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

Це створює надзвичайно небезпечну загрозу: цензура.

Якщо деякі Builder під тиском відповідності, комерційної конкуренції чи просто не схвалюють певні приватні умови, навмисно ігнорують вашу легітимну транзакцію в мемпулі й відмовляються включити її до блоку, навіть якщо у вас є приватний ключ і достатньо газу, ваша транзакція може бути зупинена поза ланцюгом (додаткове читання: «Записування опору до цензури в протокол: хто вирішує, чи може транзакція Ethereum бути додана до ланцюга?»).

Якщо децентралізація не може забезпечити навіть найпростіший «доступ до транзакцій без цензури», то будь-яка висока пропускна здатність — це повітряний замок.

Також саме тому в планах Hegotá FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) займає таке ключове місце.

Його логіка надзвичайно проста й сувора: накласти на Builder обмеження.

За кожен слот протокол випадково обирає групу звичайних незалежних верифікаторів, які додають всі легітимні транзакції, які вони бачать у мемпулі, до «списку включення (Inclusion List)». Ви, як Builder, все ще можете вільно впорядковувати транзакції, щоб отримувати свій MEV, але блок, який ви надаєте, обов’язково повинен містити всі транзакції з цього списку.

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

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

Як відомо, раніше, коли люди обговорювали приватність, вони постійно згадували нульові знання, приховані адреси та міксер-пули, але якщо Builder визначить, що це виклик до приватного контракту, він просто відмовить вам — і ваша математична магія миттєво зупиниться.

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

Наразі, хоча більш агресивні пропозиції щодо приватності, такі як EIP-8182 (спроба впровадити протокольний нативний Shielded Pool), все ще перебувають на етапі запропонованих обговорень (Proposed), тенденція вже очевидна: приватність більше не може розглядатися як периферійна функція стороннього dapp — вона має поступово стати базовою інфраструктурою Ethereum.

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

То єдина Етеріум нарешті вирішив провести велику реформу моделі EOA-рахунків, що існувала більше десяти років.

Щиро кажучи, модель підпису приватним ключем, яку Ефіріум використовує досі, є абсолютно неприродною для трохи звичайних інтернет-користувачів:

Втрата приватного ключа означає безповоротну втрату; на кошельку є тисячі стабільних монет, але через відсутність 0,001 ETH на комісію активи тимчасово неможливо перевести; щоб скористатися DeFi, спочатку потрібно схвалити, а потім обміняти — потрібно три підписи, щоб виконати одну дію; транзакції Nonce повинні строго чергуватися — одна затримка зупиняє всю систему.

На двох попередніх етапах оновлення спільнота робила різні компроміси. Наприклад, було розроблено ERC-4337, за допомогою якого контрактні гаманці обходили протокол; а також у Pectra було введено EIP-7702, який дозволяє звичайним адресам тимчасово підключати логіку контракту для отримання гнучкості.

Але 7702 у кінцевому підсумку є тимчасовим мостом, а справжній фокус Hegotá — це справжній нативний абстрактний обліковий запис EIP-8141 (Frame Transactions).

Можна спростити це так: раніше транзакція Ethereum була жорстко зв’язана з трьома речами — хто підтверджує, що це ви (верифікація) + хто сплачує цю транзакцію (оплата Gas) + що саме потрібно зробити (виконання), а EIP-8141 розбиває ці три речі на окремі «кадри» на рівні протоколу (додаткове читання: Нативний абстрагування облікових записів + захист від квантових загроз: чому EIP-8141 ще не став головним у Hegotá Ethereum?):

• Перевірка фрейму: більше не прив’язана до фіксованих підписів ECDSA на еліптичній кривій, підтримує більш гнучкі методи перевірки, такі як Passkey, і дозволяє інтегрувати функції смартфона, наприклад, відбитки пальців та Face ID, щоб зробити зміну ключів та відновлення облікового запису більш природними;
• Фрейм оплати: Газ спонсорується нативно. Застосунки можуть напряму оплачувати газ за нових користувачів або ви можете вказати у фреймі оплати безпосереднє зняття USDC з переказу — більше не потрібні релейні сервіси для підпільної купівлі-продажу газу;
• Виконання фрейму: природно підтримує атомні пакети, авторизація та обмін — одним кроком, успіх — всі операції виконуються разом, невдача — всі відміняються одразу;

Якщо додати EIP-8250 (Keyed Nonces), який зараз обговорюється в черзі, майбутні аккаунти зможуть мати кілька паралельних треків Nonce.

Коли ці функції природним чином інтегруються в протокол, це дасть такій гаманцю, як imToken, якісну свободу у формі продукту.

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

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

Він залишається повністю під контролем користувача, як і раніше, але використання буде таким же природним, як сканування QR-коду для оплати через Alipay або розблокування за допомогою відбитка пальця.

Якщо подивитися назад на останні роки оновлень Ethereum, шлях дуже чіткий.

Dencun вирішує проблему Blob; Pectra продовжує масштабування та покращує можливості валідаторів та облікових записів; Fusaka продовжує підготовку до більшої пропускної здатності даних за допомогою PeerDAS; наступний Glamsterdam закладе основу для більш високих лімітів Gas та паралельного виконання за допомогою структурних змін, таких як ePBS та BAL.

Розширення ще не завершено, але розширення більше не є єдиною проблемою.

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

Масштабування, покращення UX та підсилення L1.

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