Всередині оновлень Ethereum: Hegotá

Що Ethlabs пріоритезує для Hegotá і чому.

Напрямок розвитку Ethereum важливий для всіх, хто будує на ньому, використовує його, тримає ETH або просто вірить у його потенціал. Хоча це майбутнє в кінцевому підсумку визначатимуть люди, застосунки та спільноти, які щодня будують на Ethereum, оновлення мережі є одним з основних способів еволюції протоколу для задоволення їхніх потреб. Hegotá — це наступне заплановане оновлення мережі Ethereum після Glamsterdam, і цей документ висвітлює погляд Ethlabs на те, що, на нашу думку, Ethereum має пріоритезувати для нього, і чому.

Ethlabs — це некомерційна R&D лабораторія для Ethereum та ETH, якій всього 8 тижнів. Наша місія — зробити Ethereum розрахунковим шаром глобальної економіки. Ми знаходимося між реальним використанням Ethereum та розробкою протоколу, і ми проводимо час, слухаючи користувачів, гаманці, застосунки, rollups, інституції, власників ETH, дослідників та команди клієнтів. Іноді ми навіть будуємо ончейн, тому що не можна побудувати арену, не беручи в ній участі! Ми віримо, що чудова інженерія протоколу має уможливлювати чудові продукти, а чудові продукти мають допомагати визначати, куди рухатися протоколу далі.

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

Для оновлення Hegotá, враховуючи всі запропоновані EIP, ми бачимо такі сфери як найвищий пріоритет для Ethereum:

1. Сильніша стійкість до цензури: Кожен повинен мати можливість провести транзакцію, незалежно від того, хто він і для чого використовує Ethereum.
2. Швидший Ethereum: Швидші блоки означають швидші підтвердження, свіжіші ончейн ціни та швидшу фіналізацію.
3. Нативна абстракція акаунтів: Акаунти повинні підтримувати passkeys, спонсоровані транзакції, оплату газу в токенах, пакетну обробку та сильнішу конфіденційність, з можливістю переходу на пост-квантові ключі.
4. Продовження масштабування L1: Застосункам потрібна потужність, яка залишається доступною та передбачуваною, навіть при стрибках попиту.

Робота у відкритому просторі є ключовою метою для Ethlabs, тому ми пишемо щотижневі оновлення і, у випадках, подібних до цього, публікуємо дуже довгі технічні матеріали, щоб поділитися нашими думками 😅. У найближчі тижні ми також опублікуємо більш стислий контент для тих, хто хоче лише основних моментів. Наступна частина буде довгою та технічною. Тим, хто прочитає все до кінця — бажаємо успіху!

Спочатку про головне: як взагалі працює процес EIP?

Перш ніж зануритися в самі пропозиції, один важливий момент: друга фаза процесу визначення обсягу Hegotá щойно розпочалася. Перша фаза обрала FOCIL як головну тему Hegotá. 6 серпня був дедлайн для пропозицій EIP, які не є головними, і процес ACD тепер перейде до оцінки оновлення Hegotá в цілому.

Всі перелічені нижче EIP наразі перебувають на стадії PFI (Запропоновано для включення), за винятком EIP, які пройшли через процес визначення головної теми. Пропонувати EIP для включення може будь-хто, і більшість з них ніколи не потрапляють у фінальне оновлення.

Зокрема, у міру виконання робіт з імплементації, пропозиції проходять через дедалі суворіші стадії перевірки та впевненості в тому, що вони будуть випущені:

• PFI (Запропоновано для включення): ідею запропоновано для оновлення. Ця стадія є дозвільною і не означає підтримки клієнтами або остаточного включення.
• CFI (Розглядається для включення): команди клієнтів розглянули пропозицію та мають намір створити прототип і протестувати її.
• SFI (Заплановано для включення): існує широка згода включити її, за умови, що імплементація та тестування продовжуватимуться успішно.

Щоб дізнатися більше про те, як працює цей процес, ми рекомендуємо переглянути коротке пояснення Тіма Бейко тут.

Організаційні моменти: як орієнтуватися в цій статті

Ми використовуємо рейтингову систему Forkcast, щоб висловити наш погляд на пріоритетність EIP для Hegotá. Щоб мінімізувати рішення, ми розподіляємо всі розглянуті EIP на чотири рівні з наступними інтерпретаціями:

• [S-рівень] наполегливо рекомендуємо включити.
• [A-рівень] рекомендуємо включити, якщо будуть вирішені перешкоди, такі як складність імплементації, аналіз впливу або впровадження.
• [B-рівень] варто, але це розтягнуто для цього оновлення.
• [D-рівень] не рекомендуємо включати в Hegotá в поточній формі.
• [формуємо думку] ми все ще формуємо свою думку щодо цього EIP.

Зверніть увагу, що це \рекомендації\ Ethlabs. Ми оцінюємо кожну пропозицію в основному з точки зору мети, специфікації та нашого розуміння ймовірної складності імплементації, за винятком випадків, де ми маємо більшу впевненість або безпосередню участь (наприклад, Frames та Quick Slots), і будемо оновлювати наш погляд на основі оцінок від ethPandaOps, команд тестування та клієнтів у міру просування процесу.

[CL] означає, що EIP впливає на клієнти рівня консенсусу, а [EL] означає, що він впливає на клієнти рівня виконання.

Зауважте, що ми є співавторами та беремо участь у кількох EIP (включаючи FOCIL, Frame Transactions та Quick Slots). Хоча ми прагнемо оцінювати всі EIP незалежно від нашої участі чи її відсутності, будь ласка, враховуйте це при оцінці нашої позиції.

Короткий зміст

Рейтинг CL

Ви можете переглянути цей конкретний рейтинг [CL] на Forkcaster тут.

Рейтинг EL

Ви можете переглянути цей конкретний рейтинг [EL] на Forkcaster тут.

А тепер, без зайвих зволікань, ось наші погляди на оновлення Hegotá станом на сьогодні, в повному обсязі:

Теми для Hegotá

0. FOCIL: посилення стійкості до цензури

EIP-7805: FOCIL вже має статус SFI і підтверджений як головна тема Hegotá. Троє членів команди Ethlabs (Франческо, Барнабе та Джуліан) є серед його співавторів, і ми повністю підтримуємо його включення. Оскільки рішення вже прийнято, ми будемо короткими. Лише мережа, яка є нейтральною до всіх, може стати коренем довіри для всіх. Саме це дозволяє Ethereum масштабуватися, щоб стати справжнім розрахунковим шаром для глобальної економіки та для кожної окремої людини в ній.

1. Quick Slots: Швидший Ethereum

12-секундний слот Ethereum — це витрати на затримку, які знижують цінність для користувача. Тому ми наполегливо рекомендуємо включити [CL] EIP-8198: Quick Slots [S-рівень] в Hegotá з чотирьох причин:

1. Покращений UX на L1 завдяки швидшому підтвердженню транзакцій.
2. Ончейн ринки на L1 працюють зі свіжішими цінами, покращуючи спреди та економіку LP.
3. Фіналізація та правило швидкого підтвердження успадковують час слота, тому обидва стають швидшими зі швидшими блоками, покращуючи інтероперабельність з Ethereum.
4. Більше пропонентів блоків за секунду означає підвищену стійкість до цензури, включаючи економічну стійкість до цензури: суму, яку потрібно заплатити, щоб тримати блоки порожніми протягом певного періоду часу.

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

Аргумент на користь початку зараз полягає в тому, що зменшення часу слота ніколи не буде одноразовою зміною. Як і з масштабуванням, реалізовані зменшення дають застосункам більше впевненості, ніж обіцянки в дорожній карті. Шлях до слотів тривалістю менше 6 секунд починається з того, щоб зробити час слота змінним, а потім змінювати його ітеративно. EIP-8198 розділяє роботу на дві частини:

• Одноразовий рефакторинг, який полегшує оновлення часу слота в специфікаціях та коді клієнта.
• Перше зменшення в Hegotá, за яким підуть подальші зменшення в наступних форках, у міру просування дорожньої карти та отримання емпіричних доказів безпеки.

Hegotá — це правильний форк, щоб оплатити одноразові витрати. ePBS в Glamsterdam вже реструктурує слот. Hegotá тоді є відносно легким форком для рівня консенсусу, вікном, яке закривається з декупльованим консенсусом в I*, тому пропускна здатність CL для одноразового рефакторингу доступна зараз так, як не буде доступна ще кілька форків.

Це означає: Ми або зобов'язуємося залишатися на 12 секундах щонайменше на наступні два роки, або досягаємо 10 секунд приблизно через рік у Hegotá, і, можливо, менше 10 секунд через рік після цього. Ці два зменшення не є теоретичними покращеннями. Вони безпосередньо приносять підвищену цінність для користувачів та покращують економіку мережі. Ми вважаємо, що настав час починати.

Найпоширеніші заперечення

Тут ми обговорюємо 4 важливі моменти, які були підняті під час попередніх обговорень з розробниками клієнтів та EF Protocol:

1. Складність імплементації: Часові інтервали слотів з мілісекундною точністю вже об'єднані в специфікації консенсусу через роботу ePBS, і існують чернетки специфікацій CL та EL для EIP-8198, з перемасштабуванням базової комісії, ліміту газу та розкладу блобів для збереження поведінки на секунду. Решта витрат — це хвіст крайових випадків у клієнтах та інструментах, які припускають фіксований час слота, плюс тестування. Одноразовий рефакторинг виконує саме цю роботу на початку. Після цього кожне зменшення є зміною параметра.

2. Доказування zkEVM: Дві основні проблеми — це відносний час доказування та постійні накладні витрати на доказування.

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

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

2.2 Доказування zkEVM в основному масштабується лінійно з розміром блоку, за винятком деяких фіксованих накладних витрат. Швидші слоти означають, що фіксовані накладні витрати оплачуються частіше, що додає більше затримки для тієї ж пропускної здатності. Враховуючи фіксований бюджет затримки, потрібно забезпечити, щоб хороша пропускна здатність все ще могла бути отримана. Тут ми бачимо дві можливості: По-перше, інженерний прогрес продовжуватиме зменшувати затримку цих фіксованих операцій. По-друге, відкладення обчислення кореня стану, як описано в EIP-7862, виводить більшу частину доказування за межі критичного шляху, що означає, що ми можемо збільшити наш бюджет затримки для нестисливих операцій. Конвергенція цих двох можливостей говорить нам про те, що швидші слоти не перешкоджатимуть значному збільшенню пропускної здатності в майбутньому.

3. Пост-квантовий перехід: Підхід декупльованого консенсусу отримав достатню підтримку, щоб вважатися стабільним щодо майбутньої архітектури консенсусу. Декуплювання означає виведення голосування за фіналізацію за межі критичного шляху виробництва блоків. Зокрема, великомасштабна агрегація PQ-підписів та всі пов'язані рекурсивні механізми STARK будуть за межами критичного шляху. Те, що залишається для виробництва блоків та отримання правила вибору форку для відстеження голови результуючого ланцюга, — це підкомітет, який, як очікується, наразі складатиметься з 512 валідаторів, а можливо, і 256. Розміри пост-квантових підписів більші, але їх комфортно поширювати в межах запропонованого часу слота в 10 секунд і, ймовірно, менше в майбутньому.

4. Смарт-контракти та інфраструктура: Залежність від часу слота в смарт-контрактах та інфраструктурі наразі досліджується. Для смарт-контрактів ми об'єдналися з Sourcify, щоб провести аналіз усіх верифікованих контрактів. Ми вивчаємо вплив оновлення часу слота на історичні корені beacon block, що зберігаються згідно з EIP-4788: Beacon block root в EVM. Що стосується інфраструктури, то, як анекдотичний приклад, Etherscan зазначив, що зміна часу слота, ймовірно, призведе до більшого навантаження, але інфраструктура була побудована під час змінного часу слотів у Proof-of-Work, тому не потребує значних змін.

2. Абстракція акаунтів: покращення UX, безпеки та конфіденційності

Ethereum та його ширша екосистема давно потребують нативної AA, яка принесе такі переваги UX, як гаманці з passkeys, спонсоровані транзакції, оплата газу в ERC20, пакетна обробка транзакцій тощо.

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

Тому ми поміщаємо нативну пропозицію AA для Hegotá, Frame Transactions, на A-рівень, не тому, що вона технічно недостатньо хороша для S, а тому, що ми хочемо врахувати ризики практичного впровадження, для вирішення яких знадобиться величезна координація. Враховуючи досвід нашої команди в AA, Ethlabs має намір відігравати значну роль у виведенні Frame Transactions на ринок, працюючи з такими зацікавленими сторонами, як L2 та гаманці, для успішного запуску нативної AA.

Тепер перейдемо до конкретних пропозицій AA для Hegotá.

[EL] EIP-8141: Frame Transactions [A-рівень]

Ми вважаємо, що EIP-8141: Frame Transactions є найкращим кандидатом для нативної системи AA Ethereum. Порівняно з іншими пропозиціями нативної AA, Frames має ряд бажаних властивостей, які роблять його унікально узгодженим з мандатом CROPS Ethereum:

• Дозвільна інновація акаунтів: логіка валідації обробляється кодом EVM, тому розробники можуть вільно розробляти будь-яку логіку валідації, на відміну від деяких інших підходів AA, які вимагають білого списку логіки валідації.
• Першокласна підтримка протоколів конфіденційності: як наслідок першого пункту, протокол конфіденційності, такий як Railgun, може обробляти логіку валідації frame-транзакцій, дозволяючи користувачам надсилати приватні транзакції, не покладаючись на централізовані ретранслятори, як це відбувається сьогодні. Це робить протоколи конфіденційності значно більш приватними та нецензурованими.
• Пост-квантова безпека: frame-транзакції були розроблені з урахуванням ширшої PQ-дорожньої карти Ethereum. Наприклад, frame-транзакції явно розроблені таким чином, щоб підписи можна було агрегувати, що дозволяє Ethereum з часом стягувати низьку плату за газ за PQ-підписи, навіть якщо окремо кожен підпис може бути дуже дорогим для валідації.

Основна слабкість Frame Transactions також випливає з її найбільшої сили: оскільки валідація обробляється кодом EVM, валідація тепер спричиняє динамічну вартість замість фіксованої, що може створити проблеми для високопродуктивних мереж, таких як L2. Ми з оптимізмом дивимося на те, що цю проблему можна вирішити за допомогою подальших EIP або ERC на основі frame-транзакцій, таких як EIP-7819, де транзакції можуть статично вказувати свою логіку валідації, щоб секвенсори могли за необхідності «скорочувати» валідацію за допомогою нативного коду. Ми також маємо намір працювати з L2 та EF для проведення бенчмарків frame-транзакцій, щоб виявити та усунути будь-які вузькі місця продуктивності.

[CL][EL] Доповнення до Frame Transactions

Існує ряд EIP, які можна розглядати як розширення Frame txs, що розвивають його можливості.

[EL] [EIP-8250: Keyed Nonces for Frame Transactions](https://forkcast.org/eips/8250/) [A-рівень]

• Ми вважаємо цей EIP концептуально частиною EIP-8141: Frame Transactions і вважаємо, що він має бути випущений разом з ним.
• Цей EIP вводить 2D-нонси для Frame-транзакцій. 2D-нонси дозволяють акаунтам надсилати паралельні транзакції в мемпул, а також дозволяють протоколам конфіденційності зберігати нуліфайери як 2D-нонси. Це важливо, оскільки 2D-нонси є спеціальним сховищем, яке коштує дуже мало для читання та зберігання, тому приватні транзакції можуть значно заощадити на газі порівняно зі зберіганням нуліфайерів у звичайному динамічному сховищі, як сьогодні. Це особливо важливо в контексті переоцінки вартості зберігання в Glamsterdam (EIP-8037: State Creation Gas Cost Increase).

[EL] [EIP-8272: Recent Roots for Frame Transactions](https://forkcast.org/eips/8272/) [B-рівень]

• Це ще один EIP, який покращує досвід використання протоколів конфіденційності з Frame-транзакціями. Протоколам конфіденційності потрібен доступ до нещодавніх коренів зобов'язань під час валідації, що, якщо зберігати у звичайному сховищі, може бути не лише дорогим, але й конфліктувати з правилами публічного мемпулу Frames. EIP-8272 вирішує ці проблеми, надаючи системний контракт для зберігання цих коренів у кільцевому буфері, який автоматично очищає старі корені.
• Ми поміщаємо його на B-рівень, оскільки цей EIP додає значну складність до frames для конкретного випадку використання, і ми не впевнені, чи може існувати більш загальний/елегантний спосіб досягнення тієї ж мети.

[CL] [EIP-8369: VOPS Profiles for FOCIL Eligibility](https://forkcast.org/eips/8369/) [B-рівень]

• Цей EIP розглядає взаємодію між Frames та VOPS (validity-only partial statelessness), що є пропозицією дозволити вузлам мемпулу зберігати лише достатньо стану для валідації транзакцій, щоб навіть у світі безстану (через zkEVM) мемпул міг залишатися стійким до цензури.
• Ми поміщаємо його на B-рівень, оскільки цей EIP сильно прив'язаний до певного бачення безстану, щодо якого спільнота ще не повністю узгодила позицію.

[EL] [EIP-7906: Transaction Assertions via State Diff Opcode](https://forkcast.org/eips/7906/) [B-рівень]

• Цей EIP покращує статичну можливість аудиту результатів транзакцій. Користувачі вже можуть стверджувати, що має статися, але не те, що нічого іншого не сталося. Доведення відсутності змін стану вимагає нового опкоду. Поєднання позитивних тверджень (наприклад, баланс WETH збільшився щонайменше на 1.5) з негативним твердженням (жоден інший стан не змінився) дозволяє користувачам обмежити повний ефект транзакції за конструкцією, без симуляції, причому апаратні гаманці є одним з очевидних бенефіціарів.
• Враховуючи складність, включення його в хардфорк було б дуже відповідальним вибором. Ми пропонуємо зробити це лише якщо (a) команди клієнтів дійсно розуміють нюанси та наслідки цього конкретного EIP, і (b) поверхня тестування та складності дуже добре зрозумілі.

[EL] Міграція EOA [B-рівень]

[EL] EIP-7851: Code-Controlled EOA Delegation [B-рівень] та [EL] EIP-8151: Account Code Restricted ecRecover [B-рівень] найкраще розглядати як парні стандарти, які разом описують історію того, як EOA можуть переходити на смарт-акаунти. У цій історії EOA спочатку делегує смарт-акаунту через EIP-7702. Потім опкод, який вводить EIP-7851, робить делегування 7702 постійним, вимикаючи кореневий ключ ECDSA. З іншого боку, EIP-8151 зробить ecrecover обізнаним про деактивацію, щоб старий ключ не міг вивести кошти через потоки типу Permit.

Ми оцінюємо цю пару на B-рівні, оскільки це лише один з багатьох підходів до міграції EOA на смарт-акаунти, і цей конкретний підхід не отримав широкого розгляду або підтримки. Зокрема, ми стурбовані тим, що цей підхід не відповідає на питання мультичейну: як та сама EOA мігрує на L2? Користувачеві доведеться виконати ту саму дію на ВСІХ ланцюгах, включаючи ланцюги, які ще не існують, що призведе до поганого UX. Ми підозрюємо, що може існувати кращий підхід, коли L2 можуть використовувати L1 як «корінь довіри» для міграції EOA, тому ми резервуємо A/S-рівні для підходів, які дозволять користувачам мігрувати один раз для всіх EVM-ланцюгів.

[EL] Схема PQ-підпису [A-рівень]

Hegotá має встановити надійний шлях до пост-квантових підписів, але ми повинні підтвердити правильний механізм, перш ніж брати на себе зобов'язання.

• EIP-8355: Add ML-DSA verification прекомпіляції, що робить пост-квантову безпеку акаунтів конкретною разом із Frame Transactions.
• Альтернатива: Попередньо зареєструвати підтримку PQ без її активації або визначити формат деривації, який зможе вмістити PQ-ключі пізніше.

[EL] EIP-7819: SETDELEGATE instruction [A-рівень]

• З огляду на те, що нативна AA, ймовірно, з'явиться в Hegota, важливо, щоб вартість розгортання нових смарт-акаунтів була низькою, але розгортання акаунтів насправді стане дорожчим у Glamsterdam через EIP-8037. За допомогою EIP-7819 нові акаунти використовуватимуть прості делегуючі вказівники замість проксі-контрактів, що значно зменшить обсяг нового стану, який потрібно створити, тим самим зменшуючи вартість розгортання.
• Ми поміщаємо цей EIP на A-рівень, оскільки вважаємо, що нижча вартість розгортання акаунтів значно зменшить тертя для впровадження AA.

3. Інженерія продуктивності: продовження масштабування L1

Glamsterdam ознаменував зміну в тому, як Ethereum підходить до R&D, де продуктивність розглядається як першокласне обмеження R&D, як у дизайні протоколу, так і в роботі клієнтів. Відкладене виконання, переоцінка ресурсів та велика кількість роботи з оптимізації клієнтів дозволили масштабуватися з 30M до (принаймні) 200M за останні два роки. Загалом, робота над продуктивністю дає нам варіанти: отриманий запас міцності можна використати для масштабування, скорочення слотів, зниження вимог до вузлів або всього перерахованого.

Сьогодні ми все ще вважаємо продовження масштабування необхідністю. Застосунки вирішують, де будувати, ґрунтуючись не лише на поточних цінах, але й на тому, чи зможе Ethereum передбачувано розширювати пропозицію блокового простору з часом. Послідовне забезпечення збільшення дає більше впевненості, ніж самі лише зобов'язання в дорожній карті. Потужність мейннету також все ще досить далека від можливості впоратися зі стрибками попиту: на одинадцятий день народження Ethereum щоденна медіанна базова комісія становила лише ~0.1 гвея, але карбування NFT підняло її вище 10 гвеїв на деякий час, при цьому медіанна вартість транзакції досягла приблизно $1, а 90-й перцентиль — більше $5. Тому масштабувальний поштовх Glamsterdam має продовжитися в Hegotá.

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

[EL] EIP-8131 та EIP-8279 [S-рівень]: Пакет переоцінки даних

Після Glamsterdam наступним обмежувальним фактором є поширення корисного навантаження, частково тому, що різні джерела байтів корисного навантаження відображаються непослідовно або взагалі не враховуються в газовому обліку. EIP-8131: Unified Transaction Content Floor розширює існуючу мінімальну вартість транзакції на вміст, відомий до виконання, тоді як EIP-8279: Block Access List Byte Floor охоплює байти BAL, створені динамічно під час виконання.

Це динамічне вимірювання робить EIP-8279 явно складнішим з двох. Однак ми пропонуємо розглядати їх як єдиний пакет. Разом вони встановлюють послідовний облік байтів, пов'язаних з транзакцією, обмежуючи найгірший випадок корисного навантаження, залишаючи більшість звичайних транзакцій, не навантажених даними, без змін. Це усуває прогалину в обліку ресурсів і відкриває шлях для подальшого збільшення газових лімітів.

[CL][EL] EIP-8146: Block Access List Sidecars [A-tier]

EIP-8146 доповнює переоцінку, покращуючи сам критичний шлях, поширюючи BAL окремо від корисного навантаження, що покращує поширення та дає клієнтам виконання перевагу в попередньому виборці стану та обчисленні пост-стану. Ми вважаємо це низько висячим фруктом оптимізації, який не варто залишати на столі. Робота з впровадження в основному знайома механіка CL gossip, що робить цей EIP легким у реалізації та високоцінним, особливо у форку, який, схоже, буде досить EL-важким.

Інші пов'язані EIP

[EL] CPSB Recalibration [A-tier]

• Дуже прості зміни, ми рекомендуємо залишити їх у плані та включити один з двох, якщо це буде визнано необхідним на основі запланованих збільшень газових лімітів та спостережуваного використання газу стану та виконання.
• EIP-8368: CPSB Recalibration for New Gas Limit: Заплановане продовження EIP-8037, що компенсує той факт, що вартість за байт стану (CSPB) стала статичною, а не функцією газового ліміту, виключно як спрощення реалізації та тестування. Ідея полягала в тому, щоб замінити покрокове регулювання одноразовими налаштуваннями під час форків, у міру необхідності, щоб утримувати зростання стану на цільовому рівні при збільшенні газового ліміту. Оскільки поточний CPSB був відкалібрований на ліміті газу в 150 млн, ймовірно, що в Hegotá буде виправдане коригування.
• EIP-8372: Normalized state gas limit: Все ще досить мінімальний надбудова EIP-8368, що дозволяє більш тонке налаштування, ніж просто CPSB, компенсуючи або цільовий показник зростання стану, або звичайний газовий ліміт, які можуть бути не досягнуті через відносну неправильну цінову політику.

[EL] EIP-7862: Delayed State Root [B-tier]

• Простий у специфікації, але, наскільки нам відомо, складність реалізації клієнтами не дуже добре зрозуміла. Корінь стану є всюдисущим у кодових базах.
• Хоча є певна перевага у зниженні бар'єру доступу до конкурентного білдингу (швидке обчислення кореня стану), на нашу думку, найбільша перевага EIP полягає в майбутньому (більше часу для доведення обчислення кореня стану).
• EL вже є важкою стороною Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [D-tier]

• Ми рекомендуємо відхилити: невелика вигода (незначна затримка обчислення кореня стану), не терміново, і замінений EIP-7862: Delayed State Root (який дає набагато більше часу для цього).

Інші EIP

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

Оскільки Hegotá, схоже, буде хардфорком з перекосом у бік EL, ми пропонуємо бути дисциплінованими та дотримуватися високої планки для будь-якого EIP з боку EL. Ми вважаємо, що бажано зробити Hegotá відносно легким на CL, окрім FOCIL та Quick Slots: вужчий обсяг зберігає пропускну здатність, щоб дати командам клієнтів простір для підготовки до більшого архітектурного переходу.

[CL] Емісія

Ми навмисно не присвоюємо EIP-8363: Tapered Issuance Burn рівень. Ми вважаємо, що емісія не є рішенням, яке основні розробники повинні приймати самостійно, а список рівнів є явною рекомендацією для основних розробників. Для більшості EIP процес ACD працює добре, оскільки рішення є переважно технічними, і спільнота фактично делегувала їх основним розробникам. Емісія відрізняється тим, що це питання монетарної політики, щодо якого сама спільнота має досягти приблизного консенсусу. Думки основних розробників мають значення, але як внесок у це публічне обговорення. Ранжування EIP-8363 разом з іншими EIP розглядало б його як звичайне рішення ACD, чим воно, на нашу думку, не повинно бути.

Технічно ми бачимо сенс у зміні емісії відповідно до EIP-8363. Проблеми, які він вирішує, є реальними: довіра до скорочення частки (slashing) знижується в міру того, як все більше ETH ставиться, високі коефіцієнти стейкінгу означають, що винагороди в основному компенсують розмивання, а ефект масштабу продовжує збільшувати розрив між великими операторами та соло-стейкерами. Зміна також має ризики, від невизначеності ефектів до розподілу часток і скидання годинника закостеніння монетарної політики. Тред Ансгара викладає обидві сторони та відображає нашу позицію. Деякі з нас раніше виступали за зміни емісії і продовжують вірити в цей шлях.

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

[CL] Функції стейкінгу

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

[CL] EIP-8015: Remove deposit and eth1data fields [A-tier]

• Дуже просте очищення технічного боргу. Завдяки EIP-7688: Forward compatible consensus data structures, докази Меркла не пов'язаних полів не постраждають, тому впливу на споживачів ланцюга немає.

[EL][CL] EIP-8237: Independent CL/EL Sync [B-tier]

• Розвиває розділення beacon block та корисного навантаження, введене ePBS, дозволяючи EL та CL синхронізуватися незалежно. Ми вважаємо, що це може спростити складну частину клієнтів Ethereum.

[CL] EIP-8205: Withdrawal credentials preregistration [D-tier]

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

[CL] EIP-8148: Custom sweep threshold for validators [D-tier]

• Ми рекомендуємо відхилити. Ми вважаємо, що EIP є надто складним (новий системний контракт, новий запит на виконання, механіка CL) для своїх переваг, які ми бачимо в основному як заохочення деякої додаткової консолідації від пулу домашніх операторів. Ми не думаємо, що це матиме значний вплив на загальну консолідацію валідаторів, враховуючи, як розподілена частка.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [D-tier]

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

[CL] EIP-7716: Anti-correlation attestation penalties [D-tier]

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

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [D-tier]

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

[CL] EIP-8359: Beacon Block Reporting Field [формуємо думку]

[CL] Подальша PQ-підготовка

Ці пропозиції зменшують залишкові залежності від BLS перед майбутнім постквантовим переходом.

[CL] EIP-8365: BLS withdrawal credential retirement [A-tier]

• Виводить з експлуатації застарілі облікові дані для виведення BLS, готуючи основу для спрощення протоколу та спрощуючи майбутній PQ-перехід.
• Враховуючи, наскільки це просто, ми вважаємо, що варто включити це зараз.

[CL] EIP-8367: Balance sunset for retired BLS validators [D-tier]

• Ми рекомендуємо відхилити. Ми вважаємо, що більшість валідаторів 0x0 змінять облікові дані (BLSToExecutionChange) до або після активації EIP-8365: BLS withdrawal credential retirement, або щоб вивести свої кошти, або щоб мати можливість продовжувати стейкінг. Ми не вважаємо, що існує велика терміновість у впровадженні механізму для роботи з рештою частки 0x0. Ми рекомендуємо просто включити EIP-8365 і подивитися на результат, перш ніж приймати рішення про наступні кроки.

[CL] EIP-8321: Hash-Chain RANDAO [D-tier]

• Ми рекомендуємо відхилити. Забезпечення постквантової безпеки RANDAO ізольовано дає мало безпеки на рівні протоколу, поки ключі валідаторів BLS залишаються вразливими, але додає приблизно 32 байти на валідатор, нову механіку управління секретами та механізм, який в основному служить одній меті. Ширший дизайн PQ-консенсусу залишається невизначеним. Ми підтримуємо ітеративний перехід, але його перший крок повинен слідувати узгодженій дорожній карті, а не ризикувати бути заміненим остаточним дизайном.

[EL][CL] Підготовка zkEVM

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

[CL] EIP-8025: Optional Execution Proofs [D-tier]

• EIP не вимагає хардфорку. Пропозиція об'єднати його з Hegota є виключно вираженням пріоритетності, і ми не згодні з цим вибором. Ми вважаємо, що робота над ним повинна продовжуватися, але Hegotá не повинен блокуватися через нього.
• Перш ніж випускати опціональні докази, ми повинні спочатку визначити кінцевий стан, а потім прискорити рух до нього, а не випускати опціональні докази без чіткого бачення довгострокової моделі валідатора/стану.
• Ключове відкрите питання полягає в тому, яку роль повинні відігравати валідатори щодо стану: чи повинні вони продовжувати обслуговувати або зберігати його частину, замість того, щоб стати повністю безстатевими. Оскільки валідатори є основною когортою нод з реальним апаратним забезпеченням та мережевою цінністю, зміни, які послаблюють цю роль, повинні мати вищу планку.

[EL] EIP-7666: EVM-ify the identity precompile [A-tier]

• корисна, невелика зміна

[EL] EIP-8200: EVMification [B-tier]

• EIP-8200 замінює три рідні прекомпіляції еквівалентним байт-кодом EVM. Два з них використовуються рідко і, здається, легко мігруються. Третій широко використовується у верифікації SNARK, тому ми хотіли б оцінити вплив, перш ніж підтримувати його видалення.
• Якщо аналіз впливу виявить низькі витрати на міграцію для постраждалих користувачів, або якщо третій прекомпіляцій буде вилучено з обсягу, ми перемістимо EIP-8200 до [A-tier].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [D-tier]

• Досить руйнівний через дуже велике збільшення вартості газу, не терміново
• Зниження ризику може включати аналіз впливу або виконання цього пізніше з певною формою прогріву на рівні блоку (або ad-hoc прогрів цих значень) для зменшення впливу.

[EL] EIP-8268: Storage Roots in Block Access Lists [B-tier]

• Може знадобитися аналіз конкретного впливу на розміри BAL та пов'язаний вплив на вартість транзакцій (EIP-8279 пропонує стягувати плату за байти BAL), оскільки запис BAL для кожного зачепленого акаунту отримує додатковий корінь trie сховища.

[EL] Функції EVM

Hegotá все ще вимагатиме деяких ad-hoc рішень щодо EVM. Ми вважаємо, що після Hegotá Ethereum повинен працювати над довгостроковою дорожньою картою EVM, сформованою ширшою екосистемою EVM. Ethlabs зробить свій внесок у це.

[EL] EIP-5920: PAY opcode [A-tier]

• Дуже простий, і ми вважаємо, що це хороший примітив для EVM
• Було б важливо краще зрозуміти конкретні випадки використання

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [A-tier]

• Дуже корисний для L2, без реальних витрат для L1 (лише інформаційний)

[EL] Повторне використання / дедуплікація коду [B-tier]

• EIP-8058: Contract Bytecode Deduplication Discount та EIP-8298: SETCODEFROM Code Reuse Instruction обидва намагаються використати той факт, що код контракту зберігається окремо від відповідного акаунту в клієнтах, з хешем коду як покажчиком між ними. Таким чином, ідентичний спільний код може зберігатися дедуплікованим. Обидва EIP дозволяють дешево встановити хеш коду акаунту на хеш коду, що існує в іншому місці.
• Ми вважаємо це привабливою загальною ідеєю, але було б важливо зрозуміти наслідки та зворотну сумісність з бінарними деревами. Наразі немає переваги між двома.

[EL] Реформа ціноутворення пам'яті [B-tier]

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

EIP-7686: Linear EVM memory limits

• Менша зміна, просто позбавляється від квадратичної вартості розширення пам'яті.

EIP-7923: Linear, Page-Based Memory Costing

• Глибша, більш принципова переробка, але складніша.

[EL] EIP-8219: Checked Arithmetic Opcodes [B-tier]

• Загалом, додавання безпечної математики до EVM здається корисним.
• Ціноутворення потрібно було б підтвердити за допомогою бенчмарків, наскільки це складно?
• З бенчмарками та аналізом впливу (скільки транзакцій могло б виграти, наскільки, які компілятори додали б підтримку?) це могло б бути A-tier.

[EL] EIP-8360: TCREATE Opcode [B-tier]

• EIP вводить можливість створювати тимчасові контракти в межах транзакції. Це хороший примітив загалом.
• EIP додає значну складність. З більш ретельною оцінкою складності реалізації та тестування, це могло б бути A-tier.

[EL] EIP-7645: Alias ORIGIN to SENDER [D-tier]

• Ми рекомендуємо відхилити: зміна, що порушує сумісність, неправильне використання ORIGIN.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [D-tier]

• Ми рекомендуємо відхилити: величезна зміна, додає залежності zk. Якщо колись і впроваджувати, то це має бути головною подією.

[EL] EIP-2488: Deprecate the CALLCODE opcode [формуємо думку]

[EL] EIP-4758: Deactivate SELFDESTRUCT [формуємо думку]

[EL] EIP-7979: Call and Return Opcodes for the EVM [формуємо думку]

[EL] EIP-8173: Foundations of EVM Control Flow [формуємо думку]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [формуємо думку]

[EL] EIP-8030: P256 algorithm support [формуємо думку]

[EL] Ціноутворення EVM

Glamsterdam підвищив ціни на недооцінені операції, які обмежували загальну пропускну здатність. Пропозиції Hegotá щодо ціноутворення EVM в основному стосуються іншої сторони: зниження цін на окремі операції, поточні витрати на які обмежують їх використання, але не масштабованість мережі. Тому це приємні доповнення з меншим впливом на кожен EIP. Ми відкриті до цільової переоцінки, але пропозиції, які вводять нові механізми вимірювання, слід включати лише в тому випадку, якщо їхній дизайн є обґрунтованим і достатньо знеризикованим відданим чемпіоном.

[EL] EIP-8358: Net Gas Metering for Account Changes [B-tier]

• Не переконані у впливі. У 900 вибіркових блоках мейннету, ~400k транзакцій: 2.07% усіх транзакцій заощадили б газ, а 1.14% газу блоку було б зекономлено.

[EL] EIP-7973: Warm Account Write Metering [формуємо думку]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [формуємо думку]

[EL] EIP-7971: Hard Limits for Transient Storage [формуємо думку]

[EL] EIP-3298: Removal of refunds [формуємо думку]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [формуємо думку]

[EL] EIP-8115: Batch priority fees at end of block [формуємо думку]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [формуємо думку]

[EL][CL] Дані виконання та індексація

[EL][CL] EIP-7668: Remove bloom filters [формуємо думку]

[EL][CL] EIP-7807: SSZ execution blocks [формуємо думку]

[EL] EIP-8116: Replace cumulative receipt fields [формуємо думку]

[EL] EIP-8304: Trustless log and transaction index [формуємо думку]

[EL][CL] Мережа

P2P-рівень Ethereum має простір для цільових покращень, особливо в тому, як транзакції, blobs та атестації поширюються мережею.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [A-tier]

• Загалом запобігає повній реконструкції та продуктивності повної ноди custody як вузького місця для масштабування кількості blob.
• Цінно, зрештою якась форма розподіленої реконструкції обов'язково повинна потрапити в протокол. Це могло б дозволити нам видалити custody валідатора.
• Потрібно краще зрозуміти складність.

[CL] EIP-8142: Block-in-Blobs (BiB) [D-tier]

• Передчасно, немає сильної терміновості, досить в останню хвилину, залишається багато питань (KZG чи ні? Нові теми gossip чи ні?).
• Не хочемо вводити KZG у критичний шлях виробництва блоків, альтернативи незрозумілі і додали б подальшої складності.

[CL] EIP-8243: Batching Attestations at Source [D-tier]

• Незрозуміло, чи можемо ми покладатися на це для зменшення часу до фіналізації, це не встановлює чіткої межі навантаження.
• Стійкість механізму до DoS-атак не повністю зрозуміла.

[EL] EIP-8077: eth/XX - announce transactions with nonce [формуємо думку]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [формуємо думку]

[CL] EIP-8334: Bundled Attestation Propagation [формуємо думку]

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

Ще кілька слів...

Оновлення Ethereum є складними, тому що ставки високі. Тисячі нод по всьому світу переходять на нові правила в один і той же слот, і мережа не зупиняється ні на секунду, поки вони це роблять. Ця строгість супроводжувала кожне оновлення, яке коли-небудь випускав Ethereum, що призвело до створення децентралізованої мережі, яка відсвяткувала 11 років 100% безвідмовної роботи.

Наші позиції щодо Hegotá є нашими найкращими оцінками на сьогоднішній день, але ми оновимо наші думки щоразу, коли нові докази з обговорень або роботи з впровадження змінять нашу точку зору.

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

Ми вдячні бути маленькою частиною цієї екосистеми і з нетерпінням чекаємо на допомогу Ethereum у реалізації його потенціалу.

– Ethlabs