Чернетка EIP-8390 для Ethereum пропонує зменшити емісію на 33 800 ETH і відмовитися від sync committee
Ринкове зведення ШІ
Проєкт EIP-8390 пропонує прибрати 512-валідаторний sync committee Ethereum та його винагороди, що означає приблизно на 33 800 ETH меншу річну емісію консенсусу. Хоча скорочення з боку пропозиції піддається кількісній оцінці, ця пропозиція зробить застарілим інтерфейс light-client Altair і перенесе полегшену верифікацію на позамережеві докази фінальності з нульовим розголошенням, які ще не визначені, не стимульовані та не бенчмарковані. Чистий ефект — потенційний компроміс між нижчою емісією та підвищеним ризиком реалізації й залежностей для інфраструктури light-client.
Рівень впливу
● Середній
Активи, яких стосується
ETH/USDT+1.95%
Інсайт ШІ · ETH/USDTІнсайт ШІ
● Нейтральний
Торгувати
⚠️ Інсайти, згенеровані ШІ, ґрунтуються на новинних матеріалах і надаються виключно з інформаційною метою. Вони не є інвестиційною порадою та не відображають поглядів BingX. Інвестування пов’язане з ризиком. Будь ласка, торгуйте відповідально.
До офіційного репозиторію Ethereum Improvement Proposals 24 серпня о 02:04 UTC додали нову пропозицію EIP-8390 зі статусом Draft. Документ пропонує вивести з протоколу sync committee із 512 валідаторів, скасувати пов'язані з ним винагороди та фактично зробити чинний інтерфейс Altair для light client застарілим, замінивши його офчейн-доказами з нульовим розголошенням (ZK).
Sync committee — це вибірка з 512 валідаторів, чиї повідомлення дають легким клієнтам компактний спосіб відстежувати beacon chain без обробки всього набору валідаторів. EIP-8390 пропонує прибрати валідаторські обов'язки, мережеві повідомлення, контейнери даних для light client і кілька кінцевих точок Beacon API. У тексті зазначено, що розгорнуті Altair light clients, які синхронізуються через LightClientUpdate, перестануть працювати на форку. До потенційно вразливої категорії відносять реалізації, що користуються стандартним потоком оновлень Altair: Helios (вбудовується в гаманці та dApp і покладається на консенсусний endpoint із Beacon API для light client), пакет light client у Lodestar, інтерфейс light client у Nimbus, а також IBC-клієнт Ethereum від Datachain, який формує заголовки з LightClientUpdate і FinalityUpdate, отриманих через Beacon RPC. Реальний вплив форку залежатиме від того, чи використовують ці продукти вилучені інтерфейси на момент змін і які міграції запропонують підтримувачі.
Оціночна економія на емісії в чернетці подається як конкретний ефект: у формулі консенсусних винагород sync committee має вагу 2 при знаменнику 64. Прибирання цієї ваги без перерозподілу означає зниження консенсусної емісії на 2/64, тобто 1/32. EIP наводить знімок мережі з 901 505 валідаторами та 42 328 615 ETH у стейкінгу. За оцінки приблизно 1,082 млн ETH річної консенсусної емісії вилучена частка становить близько 33 800 ETH на рік.
Водночас автори підкреслюють, що розрахунок 1/32 не дорівнює автоматичному скороченню на 3,125% фактичної прибутковості кожного валідатора: мова йде про частину консенсусної емісії, яка спрямовується саме на винагороди sync committee, тоді як реалізована дохідність може включати інші консенсусні винагороди та доходи з execution layer.
У частині безпеки EIP-8390 порушує питання відповідальності за шкідливі повідомлення sync committee. Специфікація Altair не містить окремої умови слешингу для валідатора, який підписує зловмисне повідомлення sync committee. Окрема пропозиція EIP-7657, що мала додати таке покарання, зараз позначена як Stagnant. У ній також містилося застереження, що застосунки, які захищають понад 512 × 32 ETH (16 384 ETH), повинні поєднувати протокол light client з іншими механізмами захисту. Це попередження формувалося в контексті максимального effective balance 32 ETH, але воно відображає базову проблему: підписів вибірки достатньо, щоб light clients стежили за Ethereum, проте для зловмисних повідомлень sync committee немає власної протокольної умови слешингу.
Замість цього EIP-8390 пропонує перенести сигнал фінальності для light clients на перевірку ZK-доказу фінальності Casper FFG по всьому набору валідаторів. Такий доказ має стати фінальним сигналом для клієнтів, які не обробляють повний набір валідаторів. Чернетка стверджує, що фінальність Casper FFG нібито можна довести в межах однієї епохи на одному GPU, а верифікація займає мілісекунди, але не наводить відтворюваної реалізації, опису схем (circuit), профілю обладнання чи бенчмарків. Як орієнтир згадується порівнюваний публічний дизайн для full-set, де описано препроцесинг менш ніж за хвилину на 64-ядерному CPU без прискорення GPU і вказано, що частини складання фінального доказу залишаються майбутньою або ще не реалізованою роботою — тобто прогрес є, але за інших апаратних умов.
Ключова невизначеність — інфраструктура заміни. Документ не визначає сервіс генерації доказів, інтерфейс для клієнтів, модель надійності, операторів або фінансування. Також прямо зазначено, що протокол не додає стимулів для випуску доказів фінальності й не пропонує їх; теоретично це може бути забезпечено позапротокольно або через фінансування public goods.
Чернетка не містить епохи активації та не є зобов'язанням дорожньої карти Ethereum; графік, за текстом, залишається за командами клієнтів. У дискусійній гілці автора на момент початкового оновлення не було зазначено зовнішніх рев'ю. Висновок EIP-8390 у поточному вигляді зводиться до обміну: вимірюване скорочення емісії та вилучення проблемної з точки зору відповідальності вибірки — на залежність від ще не описаної й не розгорнутої системи ZK-доказів і невизначений шлях міграції для існуючих Altair light clients. Для руху до активації, як випливає з ризиків у документі, знадобляться протестований інтерфейс для light clients, робочі міграції для поточних користувачів Altair і публічне виробництво доказів, доступне тоді, коли на нього спиратимуться користувачі.