Розбір очікуваного Хардфорку Ethereum - оновлення Pectra

Вступ

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

Історія хардфорка Ethereum 2.0 Proof-of-Stake складна. Вона почалася з додавання шару символів до існуючого виконавчого шару, при цьому виконавчий шар продовжував працювати на Proof-of-Work (фаза 0 та хардфорк Altair). Потім, в хардфорку Bellatrix повністю активували PoS (хоча зняття коштів було вимкнено). Далі, в хардфорку Capella дозволили зняття коштів, завершивши життєвий цикл перевіряючого. Останній хардфорк Deneb (який став частиною оновлення Deneb/Cancun) здійснив невеликі зміни параметрів ланцюга символів, таких як вікно часу для доказів, обробка добровільного виходу та обмеження заміни перевіряючих. Основні зміни в Deneb відбулися виконавчому шарі, де було введено blob транзакції, blob газ, KZG зобов'язання для blob та було відмінено операцію SELFDESTRUCT.

Зараз, хардфорк Prague/Electra (також відомий як Pectra) вносить важливі оновлення в рівні виконання та консенсусу. Як аудитор проекту Lido, ми зосереджуємося на змінах, що стосуються консенсусу та залучення ставок в цьому хардфорку. Однак, ми не можемо ігнорувати зміни в рівні виконання в Prague, оскільки вони включають важливі функції, що впливають на мережу Ethereum та валідаторів. Давайте розглянемо деталі цих змін.

Вища оглядова інформація про Pectra

Electra вводить багато функцій на рівень маяка. Основні оновлення включають:

• Дозволяється зміна дійсного балансу перевіряючого в діапазоні від 32 до 2048 ETH (замість фіксованих 32 ETH).
• Дозволяє верифікаторам ініціювати вихід за допомогою другорядного документа "зняття грошей" (більше не потрібен ключ активного верифікатора).
• Змінено спосіб обробки депозитів Eth1 на ​​рівні бейджів (більше не розбирають події з контракту депозиту).
• Додайте нову загальну рамку для обробки запитів від звичайних контрактів Eth1 на рівні маяка (схоже на спосіб управління передоплатою Electra).

Тим часом, Прага внесла наступні зміни в рівень виконавчої влади:

• Новий попередньо скомпільований контракт, який підтримує криву BLS12-381 для перевірки доказів zkSNARK (окрім популярної кривої BN254).
• Новий системний договір для зберігання та доступу до до 8192 хеш-блоків в історії (дуже корисний для безстатевого клієнта).
• Збільшення витрат на газ calldata для зменшення розміру блока та стимулювання проектів до міграції calldata-інтенсивних операцій (наприклад, rollup) на блоби, які були введені в Dencun.
• Підтримка більшої кількості блобів для кожного блоку Eth1 та надання API для читання цих блобів. *Дозволяє ЕОА (зовнішні рахунки власності) мати власний код рахунку, що дуже розширює можливості ЕОА щодо виконання операцій, таких як виконання мультиколів або делегування виконання іншим адресам.

Давайте посилатися на відповідні пропозиції щодо вдосконалення Ethereum (EIP) для подальшої дискусії:

• EIP-7251: збільшений МАКС_EFFECTIVE_BALANCE
• EIP-7002: Вихід, який може бути спровокований виконавчим шаром
• EIP-6110: На ланцюгу надаються депозити валідаторів
• ЕІР-7549: виключити індекс комітету з доказом
• EIP-7685: Запит загального виконавчого рівня
• EIP-2537: Попереднє компілювання операцій на кривій BLS12-381
• EIP-2935: Зберігання хешу історичного блоку в стані
• EIP-7623: Додати вартість calldata
• EIP-7691: збільшення пропускної здатності blob
• EIP-7840: Додавання розкладу блоба до файлу конфігурації EL
• EIP-7702: Встановлення коду облікового запису EOA

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

EIP-7251: збільшений МАКС_EFFECTIVE_BALANCE

Зверніться до: EIP-7251

З моменту першої фази хардфорка Phase0, для підготовки до доказу власності Ethereum, до Electra, максимальний дійсний баланс валідатора був фіксований на рівні 32 ETH. Для активації валідатора потрібно мати щонайменше spec.min_activation_balance (32 ETH). Після активації валідатор починає з цього максимального дійсного балансу, але може знизити його до spec.ejection_balance (16 ETH) і бути викинутим, коли досягне цього порогового значення. Логіка "мінімальної" залишається незмінною в Electra, але зараз spec.max_effective_balance збільшено до 2048 ETH. Таким чином, валідатор може заставити від 32 до 2048 ETH для активації, і всі ці суми внесуть свій внесок у його дійсний баланс. Ця зміна позначає перехід від "32ETH-доказу власності" до "доказу власності" :)

Цей змінний залишок буде використовуватись зараз:

• Збільшити ймовірність стати пропонентом блоку, пропорційно до ефективного залишку
• Ймовірність стати членом комітету з синхронізації збільшується пропорційно до ефективного залишку
• Як основу для обчислення відносного зменшення та неактивної санкції

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

Інший вплив пов'язаний зі зменшенням. Всі штрафи за зменшення відносяться до дійсного залишку валідатора в пропорції.

• Знижка на штрафи «негайна» та «відкладена» більша для валідаторів з високими ставками залогу.
• З високо ставкою забезпеченого зменшеного валідатора також більше штрафу за "затримку" зменшення, оскільки частина "зменшеного" від загального заставу стає більшою.
• Поскаржитися на високу залишкову балансування валідатора отримує більш велику частку зменшення застави.

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

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

У зв'язку зі збільшенням ефективного залишку, змінилося також «обмеження заміни» перевіряючого. У старій версії Ethereum, звичайно, мають однаковий діючий залишок, обмеження заміни визначено як «не більше 1/65536 (spec.churn_limit_quotient) загального залогу може бути витягнуто за один цикл». Це створює «фіксовану» кількість вибуваючих перевіряючих із однаковим залогом. Однак у новій версії може бути випадок, коли виходять лише декілька великих гравців, оскільки вони представляють значну частину загального залогу.

Іншим важливим аспектом є зміна ключів багатьох перевіряючих на одному екземплярі перевіряючого. Великі перевіряючі наразі змушені працювати з тисячами ключів перевіряючих на одному екземплярі, щоб пристосуватися до великих ставок, розбиваючи їх на частини по 32 ETH. З Electra це вже не є обов'язковим. Фінансово ця зміна майже не впливає, оскільки винагорода та ймовірність лінійно масштабуються з сумою ставки. Тому 100 перевіряючих по 32 ETH еквівалентні одному перевіряючому по 3200 ETH. Крім того, декілька активних ключів перевіряючих можуть мати один і той же вилучений документ Eth1, що дозволяє виводити всі винагороди на одну адресу ETH, уникнувши збитків газу, пов'язаних з об'єднанням винагород. Однак управління великою кількістю ключів призводить до додаткових витрат на управління.

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

Підсумовуючи:

• Для невеликих незалежних перевіряючих Electra вводить можливість автоматичного збільшення їх дійсного залишку (і винагороди). Раніше будь-який залишок понад 32 ETH можна було вивести, але після Electra цей залишок в кінцевому підсумку буде спрямований на їх дійсний залишок. Однак дійсний залишок можна збільшити лише кратно spec.effective_balance_increment (1 ETH), що означає, що збільшення відбувається лише після досягнення наступного "порогу 1 ETH".
• Для великих незалежних перевіряючих, Electra забезпечує значне спрощення управління шляхом дозволу об'єднання кількох ключів активних перевіряючих в один. Хоча це не змінить правил гри, управління заставою 1x2048 безумовно набагато простіше, ніж управління заставою 64x32.
• Для постачальників ліквідності ставок, вони збирають невеликі ставки від користувачів та розподіляють їх між перевіряючими, Електра додає більше гнучкості в схему розподілу ставок, але водночас вимагає серйозного перебудови бухгалтерії перевіряючих з фіксованим залишком 32 ETH.

Ще однією важливою темою є історичні дані та оцінка прибутку для валідаторів, що особливо важливо для нових учасників, які намагаються оцінити ризики та винагороду. До появи Electra (на момент написання цього тексту), максимальне обмеження в 32 ETH (будь то мінімальне чи максимальне, фактично) створило однорідність в історичних даних. Весь ефективний залишок валідаторів, винагорода, індивідуальні штрафи за зменшення, частота пропозицій блоків та інші показники є однаковими. Ця однорідність дозволила Ethereum тестувати свій механізм консенсусу без статистичних викидів, збираючи при цьому цінні дані про мережеву поведінку.

Після Electra відбудуться значні зміни в розподілі стейкінгу. Великі валідатори частіше братимуть участь у комітетах з пропозицій щодо блоків і синхронізації, стикатимуться з більшими штрафами за скорочення подій і матимуть більший вплив на відкладений слеш, черги активації та черги виходу. Хоча це може створити проблеми в агрегації даних, консенсус Ethereum гарантує, що нелінійні обчислення будуть мінімальними. Єдиний нелінійний компонент використовує sqrt(total_effective_balance) для розрахунку базової винагороди, яка застосовується до всіх валідаторів. Це означає, що винагороди валідаторів і слеші все ще можуть бути оцінені на основі "per 1 ETH" (або, точніше, на основі spec.effective_balance_increment, яка може змінитися в майбутньому).

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

EIP-7002: можливість запуску виходу з верхнього рівня виконання

Зауважте: EIP-7002

У кожного перевіряючого в Ethereum є дві пари ключів: активний ключ та ключ виводу коштів. Активний публічний BLS-ключ виступає як основна ідентифікація перевіряючого в цепочці біконечі і використовується для підпису блоків, доказів, зменшення, агрегації комітету та (до EIP раніше) добровільного виходу (для розпочатку виходу перевіряючого згідно з визначеною затримкою). Друга пара ключів («доказ виводу коштів») може бути іншою парою BLS-ключів або звичайним рахунком Eth1 (приватний ключ та адреса). Тепер вивести кошти на ETH-адресу потрібно підписати повідомлення виводу, використовуючи активний приватний ключ BLS. Це змінено за допомогою цього EIP.

Фактично власники цих двох (активні і вивідні) ключів можуть бути різними. Активний ключ валідатора відповідає за перевірку обов'язків: запуск сервера, підтримання його нормальної роботи тощо, тоді як вивідний ключ зазвичай контролюється власником застави, який отримує винагороду та відповідає за кошти. На даний момент тільки власник, що контролює вивідний ключ, не може запустити вихід від валідатора, може лише вилучити винагороду. У цьому випадку власник активного ключа валідатора ефективно утримує баланс валідатора як «заручник». Валідатор може «попередньо підписати» повідомлення про вихід та передати його власнику застави, але цей надмірний метод не є ідеальним. Крім того, наразі вилучення та вихід потребують взаємодії з валідатором шару маятника через спеціальний API.

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

Цей EIP дозволяє власникам забезпечення спровокувати виведення та виходи (аналогічно існуючому процесу вкладу з використанням контракту 'депозиту'), надсилаючи стандартну транзакцію з їх адреси ETH до спеціального розумного контракту. Процес вилучення (або виходу під час достатнього забезпечення) виконується наступним чином:

• Заступник надсилає запит на виведення (запит "in") до контракту "Withdraw" системи.
• Угода стягує певні витрати (в ETH), щоб пом'якшити потенційні зловмисні атаки, і, подібно до EIP-1559, витрати збільшуються у разі зайнятості черги запитів.
• Контракт зберігає запити на зняття / виходу з гаманця «in» у своєму сховищі.
• Коли блок пропонується на рівень вказівника, запити на виведення / виходи з черги 'in' витягуються зі сховища.
• Зі шару блоків обробляється запит 'in', взаємодія з балансом активних перевіряючих, планування вихід перевіряючого, і формування запиту на зняття коштів 'out'.
• Запит на виведення коштів «out» обробляється на рівні виконання, зараховуються ETH для сторони, що забезпечує.

Хоча операції з депозитами спочатку виконуються в блокчейні Eth1, а потім «переміщуються» до бекон-рівня через чергу очікування депозитів, для зняття коштів використовується інший підхід. Вони спочатку запускаються на рівні бекону (за допомогою CLI), а потім «переміщуються» до блокчейну Eth1. Зараз обидва підходи будуть працювати за однією загальною рамкою (як описано нижче): створення запиту на рівні Eth1, обробка черг очікування депозитів / виводів / злиття та обробка на рівні бекону. Для операцій, таких як вивід, черга виведення також буде оброблятися, а результат буде розраховуватися в блокчейні Eth1.

Через цей EIP залоговий власник може вилучити та вийти зі свого валідатора за допомогою звичайної ETH-операції, без прямого взаємодії з валідатором CLI або доступу до його інфраструктури. Це значно спрощує процес залогу, особливо для великих постачальників залогу. Інфраструктура валідатора тепер може бути практично повністю відокремлена, оскільки потрібно лише підтримувати ключі активних валідаторів, а всі операції залогу можуть бути оброблені в іншому місці. Він усуває потребу в самостійних залогових власниках очікувати дій активних валідаторів і значно спрощує зовнішню частину служби, такої як модуль стейкінгу спільноти, як Lido.

Отже, цей EIP «завершує» операцію ставок, повністю переносить її на рівень Eth1, значно знижуючи ризики безпеки інфраструктури та посилюючи децентралізацію незалежної ініціативи щодо застави.

EIP-6110: забезпечення депозитів перевіряючих учасників на ланцюжку

Див. EIP-6110

Наразі депозит здійснюється за допомогою події в контракті 'Депозит', яка взаємодіє з системою (докладно розглянуто в попередній статті). Контракт отримує ETH та підтвердження від валідаторів, видає подію 'Deposit()', яка потім розбирається та перетворюється на запит на депозит на рівні маяка. Система має багато недоліків: вона вимагає голосування за eth1data на рівні маяка, що призводить до значної затримки. Крім того, маяковий рівень повинен запитувати виконавчий рівень, що подальше ускладнює ситуацію. Ці проблеми докладно обговорюються в EIP. Простіший спосіб, який уникне багатьох цих проблем, - це безпосередньо включити запит на депозит в блоки Eth1 на визначеному місці. Цей механізм схожий на процес обробки виведення, описаний раніше в EIP.

Зміни, запропоновані в цьому EIP, мають великий потенціал. Обробка eth1data тепер може бути повністю видалена, не потрібно більше голосувати або чекати довгий час між депозитами, що містяться на рівні подій Eth1 та бейджа (приблизно 12 годин на даний момент). Вона також вилучає логіку знімка контракту депозиту. Цей EIP спрощує обробку депозитів та забезпечує її вирішення відповідно до зазначеної вище схеми обробки зняття коштів.

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

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

EIP-7685: Запит загального виконавчого рівня

Див. EIP-7685

Цей EIP мав бути представлений перед першими трема EIP, пов'язаними з депозитами / вилученнями / злиттям, оскільки він покладає фундамент для цих EIP. Проте його введення тут призначене для акцентування зростаючої потреби в спеціалізованих даних для забезпечення консистентності між блоками (шаром) Eth1 (виконання) та сигнальними (консенсус) ланцюгами. Цей EIP впливає на два шари, що робить обробку запитів, що спровоковані звичайними ETH-транзакціями, більш ефективною. Наразі ми спостерігаємо:

• Подія збереження в блоках Eth1 "переміщується" для обробки в блоках вказівника.
• Запит на зняття коштів з блоку маяка (з використанням CLI) «переміщено» для обробки в блок Eth1. запит маяка.

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

Ця EIP надає рамки для принаймні трьох основних випадків: депозит, вилучення та об'єднання. Тому ранні версії EIP включали поля, такі як WITHDRAWAL_REQUEST_TYPE та DEPOSIT_REQUEST_TYPE, а тепер об'єднання додає ще одне поле - CONSOLIDATION_REQUEST_TYPE. Крім того, ця EIP може також включати загальний механізм обмежень для обробки таких запитів (див. константи: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

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

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

EIP-2537: Прекомпіляція для операцій на кривій BLS12-381

Див. також: EIP-2537

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

Математичні операції над еліптичними кривими, такими як BLS12-381 (і її відповідник BN-254), наразі використовуються головним чином для двох цілей:

• Підпис BLS використовує спеціальну операцію, відому як «пара», для перевірки цих підписів. Підписи BLS широко використовуються перевірювачами, оскільки вони дозволяють агрегувати кілька підписів в один. Перевірювачі покладаються на підписи BLS, основані на кривій BLS12-381 (хоча вони також можуть використовувати будь-яку реалізацію кривої, яка підтримує парування, таку як BN254).
• Перевірка доказів zkSNARK, де парність використовується для перевірки доказів. Крім того, для перевірки обіцянок блоків KZG великих блоків, введених розгалуженням Dencun, також використовується парність.

Якщо ви хочете перевірити підпис BLS або довести zkSNARK в розумових контрактах, вам потрібно обчислити ці «пари», що є дуже дорогим з обчислювальної точки зору. У Ethereum вже є попередньо скомпільований контракт для операцій з кривою BN254 (EIP-196 і EIP-197). Однак крива BLS12-381 (яка вважається більш безпечною та широко використовується сьогодні) ще не реалізована як попередньо скомпільований контракт. Без такого попереднього скомпілювання реалізація пар та інших операцій з кривими в розумових контрактах потребує значних обчислень, як показано тут, і вимагає великої кількості газу (приблизно ~10^5 до 10^6 газу).

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

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

EIP-2935: Збереження історичних хеш-блоків у стані

Див. також: EIP-2935

Цей EIP пропонує зберігати 8192 (приблизно 27,3 години) хешів минулих блоків у стані блокчейну для розширення історії для клієнтів без стану (наприклад, rollup) та розумних контрактів. Він пропонує зберігати поточну поведінку операційного коду BLOCKHASH, зберігаючи обмеження на 256 блоків, одночасно вводячи новий системний контракт, спеціально призначений для зберігання та отримання історичних хешів. Цей контракт виконує операцію set() при обробці блоків на рівні виконання. Його метод get() доступний для будь-кого, хто має доступ до отримання необхідних хешів блоків з кільцевого буфера.

Наразі у EVM є можливість посилатися на хеші старих блоків, але доступ обмежений останніми 256 блоками (приблизно 50 хвилин). Однак у деяких випадках доступ до старих блоків є надзвичайно важливим, особливо для міжланцюжкових застосунків (які потребують доказів даних попередніх блоків) та безстатевих клієнтів, які регулярно потребують доступу до хешів ранніх блоків.

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

EIP-7623: Додана вартість calldata

Див. також: EIP-7623

calldata впливає на доступний розмір корисного навантаження транзакції та може бути значним у деяких випадках (наприклад, коли передається великий масив або буфер бінарних даних як параметр). Використання calldata переважно пов'язане з rollup, які відправляють корисне навантаження, включаючи поточний стан rollup, через calldata.

Введення великих, підтверджуваних бінарних даних в блокчейн є важливим для rollup. Оновлення Dencun (Deneb-Cancun) вводить важливе нововведення для таких випадків використання - транзакції blob (EIP-4844). Транзакції blob мають власну витрату на газ «blob», і хоча їх тіло тимчасово зберігається, їх криптографічне підтвердження (зобов'язання KZG) разом з їх хешем інтегрується на рівні консенсусу. Таким чином, для rollup, blob надає краще рішення, ніж зберігання даних за допомогою calldata.

Поощрення rollup перемістити свої дані до краплі може бути досягнуто шляхом “моркви та палиці”. Зниження вартості газу для краплі слугує “морквою”, а цей EIP, збільшуючи витрати на calldata, виступає як “палиця”, тим самим стримуючи надмірне зберігання даних у транзакціях. Цей EIP доповнює наступний EIP-7691 (Збільшення пропускної здатності краплі), який збільшує максимальну кількість крапель, дозволених для кожного блоку.

EIP-7691: збільшення пропускної здатності blob

Див. : EIP-7691

У попередньому хардфорку Dencun було введено blob, і початкові значення максимальної та цільової кількості blob на "кожен блок" були консервативно оцінені. Це сталося через складність передбачення того, як мережа p2p буде обробляти великі бінарні об'єкти, що поширюються між вузлами перевірки. Попередня конфігурація показала себе добре, що робить це відповідним часом для перевірки нових значень. Раніше кількість blob на кожен блок було встановлено на 3/6. Ці обмеження тепер збільшено до 6/9.

Враховуючи попередній EIP-7623 (збільшення вартості calldata), ця корекція додатково стимулює rollup перенести свої дані з calldata до blobs. Робота з пошуком найкращих параметрів blob продовжується.

EIP-7840: Додавання розкладу blob до файлу конфігурації EL

Дивіться: EIP-7840

Цей EIP пропонує додати ціль та максимальну кількість блобів "на блок" (як обговорювалося раніше), а також значення baseFeeUpdateFraction до конфігураційного файлу екзекуційного рівня Ethereum (EL). Він також дозволяє клієнтам отримувати ці значення через API вузлів. Ця функціональність особливо корисна для завдань, таких як оцінка витрат на газ блобу.

EIP-7702: Встановлення коду облікового запису EOA

Дивіться: EIP-7702

Це дуже важливий EIP, який принесе значні зміни користувачам Ethereum. Як ми знаємо, EOA (Outternally Owned Accounts) не може мати жодного коду, але може надавати підписи транзакцій (tx.origin). На відміну від нього, смарт-контракт має байт-код, але не може активно пропонувати прямий підпис «його». Будь-яка взаємодія з користувачем, яка потребує додаткової, автоматизованої та перевіреної логіки, наразі може виконати лише бажану дію за допомогою виклику зовнішнього контракту. Однак у цьому випадку зовнішній контракт стає msg.sender наступного контракту, здійснюючи дзвінок «від контракту, а не від користувача».

Цей EIP вводить новий тип транзакції SET_CODE_TX_TYPE=0x04 (ми маємо старий тип транзакції 0x1, новий тип транзакції від Берлінського та EIP-1559 оновлення 0x02, а також блоб-транзакцію 0x03, впроваджену в Dencun). Цей новий тип транзакцій дозволяє встановлювати код для облікового запису EOA. Фактично, це дозволяє EOA виконувати зовнішній код "в контексті свого власного облікового запису EOA". З зовнішнього погляду, на час виконання транзакції EOA, здається, що він "позичає" код від зовнішнього контракту та виконує його. Технічно це досягається шляхом додавання спеціального кортежу авторизаційних даних до сховища "коду" адреси EOA (до цього EIP це сховище "коду" завжди було порожнім для EOA).

Наразі новий тип транзакції 0x04, запропонований цим EIP, містить масив:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Кожен елемент дозволяє обліковому запису використовувати код з вказаної адреси (з останнього дійсного дозволу). Під час обробки таких операцій код облікового запису EOA встановлюється як спеціальне значення 0xef0100 || адресне значення (23 байти), де адреса вказує на контракт з необхідним кодом, || позначає з'єднання, 0xef0100 позначає спеціальне магічне значення, яке не може міститися в звичайному розумному контракті (згідно з EIP-3541). Це магічне значення забезпечує, що цей EOA не може розглядатися як звичайний контракт і не може бути викликаний так само, як звичайний контракт.

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

Одним з головних впливів є можливість прямого виклику (multicall) з EOA. Multicall є поширеним трендом у DeFi, і багато протоколів надають цю функціональність як потужний інструмент (наприклад, Uniswap V4, Balancer V3 або Euler V2). Завдяки цьому EIP тепер можна прямо викликати multicall з EOA.

Наприклад, ця нова функція вирішує поширену проблему в DeFi: низька ефективність approve() + anything() вимагає двох окремих угод. Цей EIP дозволяє загальну логіку «передавання дозволу», що дозволяє виконати approve(X) + deposit(X) в одній угоді.

Ще однією перевагою, яка полягає в можливості "представляти" виконання делегованої угоди EOA, є концепція спонсорства. Спонсорство - це часто обговорювана й високо бажана функція, спрямована на допомогу новим користувачам у вступі до Ethereum.

Програмований логічний розблокування, пов'язане з EOA, відкриває багато можливостей, таких як впровадження обмежень безпеки, встановлення верхньої межі витрат, обов'язкові вимоги KYC тощо.

Звичайно, цей зсув також викликає низку питань щодо дизайну. Однією з проблем є використання ланцюжка_id, який визначає, чи може один і той самий підпис бути дійсним у кількох мережах, залежно від того, включений він чи не включений до підпису. Ще однією складністю є вибір між використанням адреси об'єктного коду та вбудовуванням фактичного байт-коду. Обидва методи мають свої унікальні особливості та обмеження. Крім того, використання nonce відіграє ключову роль у визначенні того, чи є дозвіл «багатоцільовим» чи «одноцільовим». Ці елементи впливають на функціональність і проблеми безпеки, включаючи такі аспекти, як масове визнання підписів недійсними та простота використання. Віталік порушив ці питання під час дискусії (тут), яку варто дослідити далі.

Важливо зауважити, що ця зміна вплине на один з механізмів безпеки Ethereum, tx.origin. Деталі реалізації цього EIP є необхідними, але, здається, зміниться поведінка require(tx.origin == msg.sender). Ця перевірка завжди гарантувала, що msg.sender - це EOA, а не контракт, і була найнадійнішим способом. Інші методи, такі як перевірка EXTCODESIZE (для перевірки наявності контракту), зазвичай зазнають невдачі та можуть бути оминуті (наприклад, шляхом виклику конструктора або розгортання коду на попередньо визначеній адресі після угоди). Ці перевірки використовуються для запобігання рекурсивних викликів та атак миттєвих кредитів, але вони далеко не є ідеальними, оскільки також перешкоджають інтеграції зовнішніх протоколів. Після цього EIP навіть надійна перевірка require(tx.origin == msg.sender), здається, застаріла. Протоколи повинні адаптуватися, видаляючи ці перевірки, оскільки різниця між "EOA" та "контрактом" вже не застосовуватиметься - тепер кожна адреса може мати відповідний код.

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

Висновок

Модернізація Prague/Electra (Pectra) запланована на березень 2025 року. Деякі з найбільш помітних змін у програмі включають:

• Змінні перевірювачі мають можливість ставити ефективне заставу, максимальна сума якої може досягати 2048 ETH. Це значно змінить розподіл застав, графік перевірювачів і, шляхом інтеграції менших застав, спростить управління великими постачальниками застави.
• Покращення взаємодії рівня виконання та рівня згоди, спрощення обміну даними між блоками виконання Eth1 та блоками ланцюга маятника. Це значно спростить процеси депозитів, активації, вилучення та виходу, прискорить ці процеси та закладе основу для подальшої взаємодії між рівнем згоди та рівнем виконання
• Підтримка прямого використання нового "більш дружнього до пар" BLS12-381 попередньої компіляції для більш дешевого підпису BLS та перевірки zkSNARK в розумних контрактах.
• Заохочується використання Rollups шляхом збільшення порогу blob-транзакцій та підвищення вартості calldata
• Зробити EOA функціональним обліковим записом, що дозволяє йому виконувати багаторазові виклики, спонсорування та інші високорівневі функції

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