Які EIP вже точно будуть включені в оновлення Pectra? Чи призведе це до зростання інфляції ETH?

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

Автор: 0XNATALIE

Наступне оновлення Ethereum Pectra отримало свою назву від поєднання Prague та Electra.

Prague означає оновлення виконувального шару, назване на честь міста Прага, де проходила конференція розробників Ethereum (Devcon 4), а Electra символізує оновлення шару консенсусу, назване на честь зірки за алфавітним порядком. Обрана зірка Electra відповідає літері «E».

Оновлення Pectra може стати хардфорком в історії Ethereum, який охоплює найбільшу кількість Ethereum Improvement Proposals (EIP). Воно включає низку пропозицій щодо покращення роботи валідаторів та продуктивності основної мережі, а також вводить пропозиції для оптимізації L2. Тестова мережа Pectra Devnet 4 щойно запущена, і наразі вже 8 EIP підтверджено для включення в оновлення Pectra.

Підтверджені EIP та їхній вплив

Ці 8 EIP впливають на користувачів так: додавання можливості виконання коду для EOA підвищує гнучкість акаунтів, дозволяючи виконувати складніші операції; підвищення ліміту стейкінгу може збільшити попит на ETH; оптимізація процесу валідації підвищує безпеку та ефективність, збільшуючи швидкість і пропускну здатність Ethereum.

1. EIP-2537 (підтримка BLS-підписів): шляхом впровадження низки попередньо скомпільованих контрактів (precompiles) додає підтримку обчислень кривої BLS12-381 для Ethereum, дозволяє перевіряти BLS-підписи та агрегувати кілька підписів в один, зменшуючи складність валідації. BLS-підпис — це криптографічний алгоритм, який дозволяє створювати компактні підписи та підтримує їхню агрегацію. Це допоможе L2, які потребують великої кількості перевірок підписів і даних, працювати ефективніше.
2. EIP-2935 (зберігання хешів історичних блоків у стані): зберігає хеші останніх 8192 блоків у системному контракті для підтримки моделі Stateless Clients та забезпечує гнучкіший запит історичних хешів блоків. Ці хеші можна запитувати напряму через контракт і надавати як доказ (witness) безстанним клієнтам. Клієнтам не потрібно зберігати повну історію блокчейну чи великі обсяги даних — достатньо покладатися на хеші блоків, збережені у стані, та відповідні докази для перевірки легітимності блоків і транзакцій.
3. EIP-6110 (депозити валідаторів на ланцюгу): переносить обробку депозитів валідаторів із шару консенсусу на виконувальний шар, здійснює обробку та перевірку депозитів на ланцюгу, більше не покладаючись на додатковий механізм голосування у шарі консенсусу для підтвердження дійсності депозитів. Це підвищує безпеку процесу депозиту, зменшує затримки та спрощує дизайн шару консенсусу та клієнтів.
4. EIP-7002 (вихід, ініційований виконувальним шаром): дозволяє власникам withdrawal credentials самостійно ініціювати вихід без необхідності використовувати активний ключ валідатора (BLS-ключ), підвищуючи автономію користувачів. Наразі лише активний ключ валідатора може ініціювати вихід, що означає, що у разі втрати активного ключа або делегування валідації третім сторонам (наприклад, стейкінг-провайдерам), власник withdrawal credentials (фактичний власник коштів) не може самостійно контролювати стейкований ETH. Ця пропозиція дозволяє ініціювати вихід і виведення ETH через виконувальний шар за допомогою withdrawal credentials без необхідності активного ключа.
5. EIP-7251 (підвищення ліміту стейкінгу): підвищує максимальний ефективний баланс валідатора, дозволяючи кожному валідатору тримати більше ніж 32 ETH, при цьому мінімальний поріг стейкінгу залишається 32 ETH. Мета — дозволити великим операторам вузлів об’єднувати кілька валідаторів, зменшуючи їхню кількість у мережі, а отже, знижуючи навантаження на P2P-повідомлення, агрегацію підписів і зберігання.
6. EIP-7549 (винесення індексу комітету з доказу): шляхом винесення поля індексу комітету з повідомлення Attestation (доказу) досягається ефективніша агрегація голосів консенсусу. У поточному механізмі консенсусу Ethereum кожен валідатор голосує, включаючи: LMD GHOST голосування (корінь блоку та слот), Casper-FFG голосування (джерело та ціль), індекс комітету (номер комітету валідатора). Оскільки індекс комітету включено до підписаного повідомлення, навіть якщо кілька валідаторів голосують за один і той самий блок, їхні підписи різні, що ускладнює агрегацію. Винесення індексу комітету з підписаного повідомлення дозволяє ефективніше агрегувати голоси, знижуючи вартість перевірки та навантаження на мережу.
7. EIP-7685 (універсальні запити виконувального шару): визначає універсальну структуру для виконувального шару (EL) для зберігання та обробки запитів, ініційованих смарт-контрактами. Ця структура підтримує більше дій, ініційованих виконувальним шаром, і дозволяє обробляти різні типи запитів уніфіковано, спрощуючи додавання нових типів запитів без зміни структури виконувального блоку.
8. EIP-7702 (додавання можливості виконання коду для EOA): додає зовнішнім акаунтам (EOA) можливість виконання коду, підвищуючи їхню гнучкість і програмованість. EOA можуть через підпис уповноважити смарт-контракт виконувати певні дії, наприклад, пакетні транзакції чи контроль доступу. Це дозволяє мати певні функції смарт-контракту без необхідності повністю перетворювати EOA на смарт-контрактний акаунт.

Ключові EIP, що розглядаються

Нижче наведено деякі EIP, які активно розглядаються. Вони головним чином оптимізують blob, підвищують стабільність вартості публікації даних L2, покращують обробку транзакцій L2 та ефективно знижують їхню вартість. Крім того, зміна вартості calldata може вплинути на обсяг спаленого ETH, збільшуючи інфляційний тиск на ETH.

• EIP-7742 (розв’язання залежності підрахунку blob між шаром консенсусу та виконувальним шаром): роз’єднує кількість blob між шаром консенсусу та виконувальним шаром, спрощує процес перевірки blob, зменшує зайву складність, підвищує масштабованість і гнучкість протоколу. У поточному протоколі і виконувальний, і консенсусний шари жорстко кодують максимальну кількість blob, що призводить до дублювання перевірок. Ця пропозиція скасовує перевірку максимального значення blob у виконувальному шарі, натомість консенсусний шар динамічно надає цільове значення blob виконувальному шару. Це дозволяє гнучко налаштовувати параметри blob для майбутніх потреб масштабування. EIP-7742 — одна з найменш спірних пропозицій у списку EIP, що розглядаються для включення в оновлення. За останніми даними з консенсусної зустрічі розробників, погоджено почати реалізацію EIP-7742 у pectra-devnet 5, але його остаточне включення залежить від відгуків виконувального шару на ACDE (All Core Devs Execution Layer Meeting).
• EIP 7762 (мінімальна базова плата за blob): підвищує MIN_BASE_FEE_PER_BLOB_GAS з метою скоротити час, необхідний для коригування ціни blob до розумного рівня. Наразі мінімальна базова плата за blob становить 1 wei, і коли попит на blob перевищує пропозицію, процес визначення ціни (тобто встановлення справедливої ціни blob Gas) відбувається надто повільно, і потрібно багато часу, щоб досягти відповідного рівня. Підвищення мінімальної базової плати за blob дозволяє швидше коригувати ціну, забезпечуючи швидке досягнення ринкової рівноваги та стабільність мережі під час пікового попиту.
• EIP-7623 (підвищення вартості calldata): підвищує вартість calldata у транзакціях, щоб зменшити максимальний розмір блоку та його варіативність, забезпечуючи більш плавну обробку транзакцій мережею. Поточний максимальний розмір блоку — близько 1,79 МБ, але через масові публікації даних від rollups середній розмір блоку постійно зростає. Підвищення вартості calldata, яка переважно використовується для транзакцій із забезпеченням доступності даних (DA), зменшить максимальний розмір блоку до близько 0,72 МБ, звільняючи місце для майбутнього підвищення ліміту Gas блоку або додавання більше blob. Вартість звичайних транзакцій для користувачів не зміниться, це вплине лише на транзакції, які масово зберігають дані в Ethereum. Проте підвищення вартості calldata може знизити конкурентоспроможність Ethereum у сфері зберігання даних. Крім того, зменшення кількості транзакцій через підвищення вартості calldata може зменшити обсяг ETH, спаленого через механізм EIP-1559, що посилить інфляційний тиск на ETH.
• EIP 7782 (скорочення часу слота): скорочує час слота Ethereum з 12 секунд до 8 секунд, дозволяючи частіше створювати блоки для обробки більшої кількості транзакцій, розглядається як альтернатива збільшенню кількості blob для підвищення пропускної здатності. Проте це може порушити роботу деяких смарт-контрактів, які жорстко закодовані на 12-секундний слот, а також прискорити проблему роздування стану Ethereum, збільшуючи навантаження на зберігання та обчислення.
• EIP-7783 (поступове підвищення ліміту Gas блоку): як м’якша альтернатива EIP-7782, динамічно коригує ліміт Gas блоку, поступово збільшуючи кількість транзакцій у кожному блоці, підвищуючи пропускну здатність мережі. На відміну від прямого скорочення часу слота, поступова зміна ліміту Gas дозволяє масштабувати мережу плавніше. Ця пропозиція не потребує хардфорку, але може вплинути на дані стану.

Оскільки оновлення Pectra включає велику кількість EIP, щоб знизити складність одного оновлення та прискорити впровадження частини EIP, у травні команда інженерів Ethereum Foundation EthPandaOps запропонувала розділити Pectra на дві частини, але тоді побоювалися затримки оновлення, тому пропозицію не розглядали серйозно. У вересні дослідник Ethereum  Alex Stokes знову запропонував розділення, і цього разу розробники підтримали ідею, оскільки це дозволить завершити першу частину оновлення протягом шести місяців:

• Перша частина: включає EIP, які вже працюють у тестовій мережі Pectra Devnet (тобто вже підтверджені 8 EIP), їх відносно легко впровадити, і вони вже пройшли багато тестів.
• Друга частина: більш складні EIP (наприклад, PeerDAS, пропозиції, пов’язані з EOF) та інші, які потребують більше часу для тестування, будуть реалізовані на другому етапі. Ці пропозиції потребують подальшої розробки, аудиту та тестування, особливо ті, що стосуються координації шару консенсусу та виконувального шару.