Переслати оригінальний заголовок: Пояснення хардфорку Прага / Електра (Пектра)

представляти

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

Історія хардфорків Ethereum 2.0 з доказом частки володіння складна. Все почалося з додавання шару маяка до існуючого рівня виконання, запустивши консенсус proof-of-stake на рівні маяка, зберігаючи при цьому proof-of-work на рівні виконання (хардфорки Phase0 і Altair). Потім PoS був повністю активований на хардфорку Bellatrix (хоча виведення коштів не було ввімкнено). Згодом хардфорк Capella дозволив виводити кошти, завершивши життєвий цикл валідатора. Останній хардфорк, Deneb (частина оновлення Dencun(Deneb/Cancun)), вніс незначні зміни в параметри Beacon Chain, такі як часове вікно для включення атестацій, обробка добровільних виходів і ліміт відтоку валідаторів. Основні зміни в Dencun відбулися на рівні виконання, впроваджуючи такі інновації, як транзакції з блобами, газ BLOB, зобов'язання KZG для блобів і застаріла операція SELFDESTRUCT.

Тепер Пражський / Електра хардфорк вводить значні оновлення як на рівні виконання, так і консенсусу. Як аудитори проекту Lido, наш фокус в основному спрямований на зміни в консенсусі та стейкінгу в цьому хардфорку. Однак не можемо ігнорувати зміни на рівні виконання в Празі, оскільки вони включають критичні функції, які впливають на мережу Ethereum та валідаторів. Давайте детальніше розберемо ці зміни.

Вищий рівень огляду Pectra

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

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

Тим часом Прага вносить зміни до рівня виконання, такі як:

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

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

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

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

EIP-7251: Збільшити МАКСИМАЛЬНИЙ_ЕФЕКТИВНИЙ_БАЛАНС

Посилання: EIP-7251

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

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

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

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

Ще один ефект пов'язаний з різаними. Усі штрафи за різання пропорційні до ефективного балансу валідатора:

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

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

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

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

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

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

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

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

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

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

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

EIP-7002: Виконавчий шар виходи, що можна спровокувати

Посилання: EIP-7002

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

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

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

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

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

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

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

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

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

Посилання: EIP-6110

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

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

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

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

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

Посилання: EIP-7685

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

• Події депозитів в блоках Eth1 будуть «переміщені» з Eth1 в блоки Beacon для обробки.
• Запити на виведення у блоках маяка (за допомогою CLI) "переміщуються" до блоків Eth1 для обробки.
• Потрібно мати справу з об'єднанням валідаторів, які також є запитами Eth1->Beacon.

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

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

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

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

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 години) історичні хеші блоків у стані блокчейну, надаючи розширену історію для клієнтів безстанційних (таких як rollups) та смарт-контрактів. Він пропонує зберегти поточну поведінку опкоду BLOCKHASH, зберігаючи обмеження на 256 блоків, одночасно вводячи новий системний контракт, спеціально розроблений для зберігання та отримання історичних хешів. Цей контракт виконує операцію set(), коли рівень виконання обробляє блок. Його метод get(), доступний для всіх, отримує потрібний хеш блоку з кільцевого буфера.

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

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

EIP-7623: Збільшення вартості calldata

Посилання: EIP-7623

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

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

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

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

Посилання: EIP-7691

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

При об'єднанні з попереднім EIP-7623 (Збільшення вартості calldata), ця корекція додатково мотивує rollups переходити їх дані з calldata на блоки. Пошук оптимальних параметрів блоку продовжується.

EIP-7840: Додати розклад блобу до EL конфігураційних файлів

Посилання: EIP-7840

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

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

Посилання: EIP-7702

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

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

Наразі цей EIP пропонує, що новий тип транзакції 0x04 включає масив:

список_авторизації = [[chain_id, адреса, nonce, y_parity, r, s], …]

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

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

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

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

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

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

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

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

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

Висновок

Оновлення Прага/Електра (Пектра) заплановане на березень 2025 року. Його найважливіші заплановані зміни включають:

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

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

Відмова від відповідальності:

1. Цю статтю відтворено з [TechFlow]. Переслано Оригінальний заголовок: Пояснення хардфорка Прага / Електра (Пектра). Авторське право належить оригінальному авторові [MixBytes (МіксБайт)]. Якщо у вас є які-небудь зауваження стосовно репринту, будь ласка, зв'яжіться Команда Gate Learn, і команда якнайшвидше вирішить це відповідно до відповідних процедур.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, відображають тільки особисті погляди автора і не є жодною інвестиційною порадою.
3. Інші мовні версії статті перекладаються командою gate Learn. Якщо не зазначено інше, перекладена стаття не може бути скопійована, розповсюджена або плагіатована.