World Chain розгорнув EIP-7928 раніше за Ethereum

Будь-хто, хто керує валідаторною інфраструктурою на завантаженому L2, знає: справжнє вузьке місце — не EVM, а послідовна верифікація блоку після його збирання. Це обмеження непомітно стримує пропускну здатність кожного OP Stack ланцюга у продакшені. World Chain щойно випустив зміну, яка атакує цю проблему в лоб — і зробив це без хард форку.

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

У чому проблема

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

Як Cryptonews.net повідомив, World Chain став першим layer-2, який розгорнув потокові списки доступу блоків EIP-7928 на mainnet: валідатори отримують дані списку доступу кожні 200 мілісекунд через архітектуру Flashblocks мережі. Незалежні транзакції можна верифікувати паралельно, поки блок ще збирається. Це суттєво відрізняється від моделі виконання, яку більшість OP Stack ланцюгів використовує сьогодні.

EIP-7928 є частиною довгострокового roadmap Ethereum і, як очікується, буде включений до майбутнього оновлення Glamsterdam. Загальну картину цієї роботи можна знайти в індексі EIP. World Chain не чекав. Він розширив пропозицію через Flashblocks і активував її за допомогою runtime-прапора, тому нод-оператори можуть оновитися без координації загальномережевої зміни протоколу.

Чому це важливо для CTO, який читає це за своїм столом? Тому що операційна вартість хард форків — колосальна. Виробничі інциденти, які я спостерігав навколо координації форків, зазвичай виникають не через сам форк, а через шість тижнів дрейфу версій клієнтів з обох боків. Runtime-прапори перевертають цю динаміку. Ви тестуєте, перемикаєте, відкочуєтесь, якщо телеметрія виглядає неправильно. Це — модель випуску оператора, а не протокольного політика.

Заголовок про масштабування теж відповідає дійсності. Внутрішнє бенчмаркінгування в тестовому середовищі показало, що затримка верифікації залишалася в основному незмінною навіть при масштабуванні пропускної здатності приблизно до одного гігагазу на секунду на стандартному хмарному залізі. Один гігагаз на секунду на хмарних комодитних потужностях — це цифра, яка має змусити кожного платіжного інженера випростатися. Вона говорить: якщо це підтвердиться на mainnet, вам не потрібні bare-metal сервери, щоб встигати.

Доступні варіанти

Якщо ви обираєте L2-підложку для стейблкоїн-розрахунків, потоків переказів або платіжного продукту з прив'язкою до ідентичності, короткий список зараз незручний. Кожен варіант має свої недоліки.

Варіант 1: Стандартні OP Stack ланцюги (Base, Optimism, інші). Зріле інструментування, величезна спільнота розробників, передбачуваний roadmap, прив'язаний до темпу оновлень Ethereum. Мінус — ви успадковуєте стелю пропускної здатності Ethereum до виходу Glamsterdam, а Glamsterdam — не наступного кварталу. Ви будуєте на ланцюгу, модель масштабування якого розраховує на зростання заліза.

Варіант 2: zkEVM роллапи (zkSync, Scroll, Linea, Polygon zkEVM). Інша модель безпеки, сильна теоретична історія масштабування, але економіка provers все одно змінюється під командами кожні кілька місяців. Моя думка: для всього, що стосується регульованих платежів, централізація provers — це питання управління, на яке доведеться відповідати аудиторам, і відповідь постійно змінюється.

Варіант 3: World Chain та інші варіанти OP Stack з розширенням Flashblocks. Ви отримуєте потокові списки доступу в продакшені вже сьогодні. Ви також отримуєте систему підтвердження особи World ID, інтегровану на рівні ланцюга, — що є або функцією, або проблемою зв'язності, залежно від вашого продукту. World Chain побудований на OP Stack, захищений Ethereum і є частиною ширшої екосистеми Superchain, тому ви не втрачаєте переваги OP-компонентності.

Варіант 4: App-specific ланцюги або alt-L1. Максимальний контроль, максимальне операційне навантаження. Підходить, якщо у вас є команда, яка хоче керувати валідаторною інфраструктурою. Більшість фінтех і iGaming команд, з якими я працював, недооцінюють цю вартість приблизно на порядок величини.

Компроміс, який варто озвучити прямо: World Chain пропонує ранній доступ до примітивів масштабування ціною роботи на ланцюгу, продуктова ідентичність якого прив'язана до World ID та підтвердження особи. Якщо ваш застосунок — це перекази, стейблкоїни або платежі з прив'язкою до ідентичності, таке вирівнювання допомагає. Якщо ви будуєте загальний DeFi-протокол, який не хоче бути залежним від чіткої ідентифікаційної інфраструктури, це — тертя.

Незручна реальність: більшість команд обирають L2 на основі TVL і ліквідності мосту, а не запасу пропускної здатності. Це нормально, поки ваш продукт справді не отримає користувачів, після чого стеля пропускної здатності стає roadmap.

Що варто робити криптo та DeFi-командам

Перестаньте ставитися до вибору L2 як до одноразового рішення. Ланцюги, які випускають функції через runtime-прапори, будуть відрізнятися від ланцюгів, що чекають на хард форки Ethereum, і розрив буде зростати протягом 2026 року. Вам потрібна мобільність, а не лояльність.

Конкретно — три кроки. По-перше, пишіть контракти та інфраструктуру, припускаючи, що ви розгорнетесь принаймні на двох L2 протягом дванадцяти місяців. Це означає — жодних chain-specific прекомпіляцій, якщо ви не можете обгорнути їх за інтерфейсом. Документація для розробників Ethereum залишається найбезпечнішою базою; все, що виходить за межі стандартного EVM, — це податок на мобільність, який ви платите.

По-друге, бенчмаркуйте на цільовому ланцюгу з реальним навантаженням, перш ніж приймати рішення. Цифра World Chain в один гігагаз на секунду отримана з внутрішніх тестових бенчмарків на хмарному залізі, а не з умов mainnet зі змагальним станом. Команди, з якими я працював, регулярно бачать зниження на 30–60 відсотків при переході від синтетичних бенчмарків до реальних навантажень із гарячими слотами зберігання. Припускайте те ж саме тут.

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

Для платіжних продуктів і продуктів переказів зокрема, модель потокових списків доступу справді цікава, оскільки вона відокремлює пропускну здатність від валідаторного заліза. Це — властивість, яка вам потрібна, коли навантаження нерівномірне і транскордонне. Моя думка: якщо mainnet-показники World Chain залишаться хоча б близькими до бенчмарку, він стає відповіддю за замовчуванням для стейблкоїн-коридорів, яким потрібна стабільна затримка розрахунків під навантаженням.

Підводні камені та крайні випадки

Бенчмаркові цифри в тестових середовищах — це маркетинг, поки не доведено інше. Один гігагаз на секунду на стандартному хмарному залізі вражає, але умови тестування мають величезне значення. Стежте за mainnet-показниками при змагальному доступі до стану, змагальному упорядкуванні транзакцій і блоках з великою кількістю MEV. Паралельна верифікація найпростіша, коли транзакції справді не взаємодіють одна з одною. Реальні DeFi-навантаження взаємодіють постійно.

Модель активації через runtime-прапор має два боки. Так, нод-оператори можуть оновлюватися без хард форку. Але це також означає, що поведінка мережі може змінюватися з меншою публічною координацією, ніж вимагає типовий форк. Якщо ви ведете моніторинг, вам потрібно знати, коли перемикаються прапори. Запитайте команду World Chain про їхню частоту сповіщень і занесіть це до свого runbook.

Потокові списки доступу змінюють форму того, що валідатори бачать всередині блоку. Якщо у вас є off-chain системи, що читають проміжний стан — від індексерів до ретрансляторів мосту — перевірте, чи вони коректно працюють із потоковими даними. Виробничі інциденти, які я спостерігав навколо оновлень L2, майже завжди виникають в off-chain інфраструктурі, яка робила припущення щодо фінальності блоку, що непомітно переставали бути правдою.

Нарешті, EIP-7928 все ще є пропозицією на стороні Ethereum. Якщо Glamsterdam поставить суттєво відмінну версію специфікації, World Chain доведеться узгоджувати свою розширену реалізацію Flashblocks із тим, що потрапить до mainline. Це — ризик сумісності, який варто враховувати в будь-якому довгостроковому архітектурному рішенні.

Ключові висновки

• World Chain — перший L2, який розгорнув потокові списки доступу блоків EIP-7928 на mainnet: валідатори отримують дані списку доступу кожні 200 мілісекунд через Flashblocks.
• Активація через runtime-прапор замість хард форку — це операційна історія, яка найбільше важлива для інженерів: швидша ітерація, менші витрати на координацію.
• Тестові бенчмарки досягли приблизно одного гігагазу на секунду на стандартному хмарному залізі зі стабільною затримкою верифікації. Ставтеся до цього як до стелі, а не підлоги, поки mainnet не підтвердить.
• Для платіжних продуктів, стейблкоїнів і переказів потокові списки доступу відокремлюють пропускну здатність від валідаторного заліза — це властивість, яка справді важлива при нерівномірному навантаженні.
• Проектуйте з розрахунком на мобільність між L2. Ланцюги з runtime-прапорами будуть відрізнятися від ланцюгів із хард форками протягом 2026 року, і ви не хочете бути прив'язані до жодного з таборів.