Окрім перекладу оригіналу, ця стаття також доповнює описом інших EIP Pectra, які не були згадані в оригіналі.
Оригінальне посилання:
Ключові моменти
Pectra є наступним великим оновленням Ethereum, яке включає зміни в шарі виконання (Prague) та шарі консенсусу (Electra). Після численних труднощів з оновленням тестової мережі Pectra, остаточно було вирішено активувати оновлення основної мережі Pectra о 10:05 UTC 7 травня.
Це оновлення забезпечить ключові поліпшення для стейкінгу, масштабованості Layer 2 та користувацького досвіду (UX), закладаючи основу для майбутніх трансформацій.
Основні зміни включають: підвищення ліміту стейкінгу для валідаторів, гнучке виведення стейків, покращення абстракції облікових записів та збільшення пропускної здатності blob для підвищення ефективності та безпеки мережі.
Вступ
Від «Злиття» (The Merge) минуло 31 місяць, від оновлення «Shapella» — 24 місяці, від оновлення «Dencun» — 13 місяців, Ethereum незабаром зустріне наступне велике оновлення — жорсткий форк Pectra.
А до оновлення тестової мережі Pectra перед оновленням основної мережі були численні перешкоди.
Оновлення Pectra тестової мережі Holesky було активовано 24 лютого о 21:55 UTC, проте через помилку конфігурації програмного забезпечення клієнта (помилкові адреси контрактів депозитів Geth, Nethermind та Besu) воно було перервано, що призвело до розгалуження мережі. Розробники обговорили план відновлення мережі через масові штрафні події, спрямовані на прискорення виходу помилкових валідаторів та досягнення остаточності мережі, яка зможе бути реалізована лише до 11 березня.
Оновлення Pectra тестової мережі Sepolia відбулося 5 березня згідно з планом. Через проблеми з налаштуваннями контракту на депозит частина клієнтів виконавчого рівня (EL) мала проблеми з включенням транзакцій у блоки, але проблема швидко була вирішена, і мережа досягла фіналізації.
19 березня, для тестування виходу валідаторів, був запущений новий тестовий мережевий Hoodi, і 26 березня успішно активовано оновлення мережі Pectra.
Оновлення тестової мережі Ethereum Pectra пройшло через двомісячні труднощі, прокладаючи шлях для розгортання основної мережі, остаточно заплановано на активацію оновлення основної мережі Pectra приблизно о 10:05 UTC 7 травня.
Як і в попередніх оновленнях Ethereum, Pectra охоплює як шар виконання (EL), так і шар консенсусу (CL). Його назва відображає цей подвійний акцент: Prague (Прага) представляє оновлення шару виконання на честь місця проведення Devcon 4; Electra (Електра) символізує оновлення шару консенсусу.
Pectra є одним з найбільших хардфорків в історії Ethereum, що стосується найбільшої кількості EIP (Ethereum Improvement Proposals, пропозицій з покращення Ethereum) — 11 EIP. Він подальше оптимізує на основі оновлення Dencun минулого року, з метою покращення користувацького досвіду (UX), оптимізації роботи валідаторів та сприяння розширенню Layer 2, що, як очікується, матиме глибокий вплив на екосистему Ethereum.
У цій статті ми класифікуємо та аналізуємо різні EIP відповідно до їхніх областей.
Покращення механізму валідаторів та стекингу
Pectra оптимізує досвід роботи валідаторів у системі PoS Ethereum за допомогою трьох основних EIP:
EIP-7251: підвищення максимальної ефективної балансу (MaxEB)
На даний момент механізм стейкінгу Ethereum обмежує максимальну ефективну ставку для одного валідатора до 32 ETH, що означає, що незалежні стейкери повинні ставити по 32 ETH, а винагорода за ставку, що перевищує цей ліміт, не враховується в ефективній ставці.
EIP-7251 пропонує підвищити максимальний ефективний баланс (MaxEB) до 2048 ETH, дозволяючи діапазон стейкінгу одного валідатора розширитися до 32 до 2048 ETH, що призведе до таких наслідків:
· Підвищення гнучкості стейкінгу: стейкери можуть реінвестувати всі доходи в ефективний стейкінг-баланс, без обмеження на кратність 32 ETH. Наприклад, валідатор, який має 33 ETH, тепер може отримувати прибуток від усіх 33 ETH, підвищуючи ефективність і гнучкість капіталу.
· Зменшення кількості валідаторів: наразі в Ethereum налічується 1,05 мільйона активних валідаторів, цей EIP дозволяє великим операторам об'єднувати своїх валідаторів, що дозволяє зменшити загальну кількість та полегшити навантаження на мережу.
· Зниження навантаження на мережу: хоча більша кількість валідаторів сприяє децентралізації, це також збільшує навантаження на пропускну здатність і обчислення. Підвищення MaxEB може оптимізувати набір валідаторів та зменшити витрати на точкову комунікацію.
EIP-7002: Виконувальний рівень може ініціювати зняття
EIP-7002 подальше удосконалює функції валідаторів, дозволяючи їм безпосередньо ініціювати вихід та часткові зняття через виконавчий рівень (0x01) за допомогою підтвердження зняття.
На даний момент у валідаторів є два ключі:
Активний ключ, який використовується для виконання обов'язків з перевірки;
Ключ для виведення, що використовується для доступу та управління коштами, що знаходяться в ставці.
Раніше лише активні ключі могли ініціювати вихід, тоді як ключі для зняття не могли діяти самостійно. EIP-7002 дозволяє також ключам для зняття ініціювати зняття, що призводить до:
· Більший контроль над фінансами: валідатори можуть безпосередньо керувати коштами, не покладаючись на операторів вузлів.
· Підтримка повністю бездоказових пулів для стейкінгу, що підвищує безпеку та рівень децентралізації.
EIP-6110: зберігання депозитів валідаторів в блокчейні
Наразі, коли нові валідатори вносять депозит на виконавчому рівні, їм потрібно чекати, поки рівень консенсусу ідентифікує та обробить це, що призводить до затримки активації.
EIP-6110 дозволяє виконавчому рівню безпосередньо передавати інформацію про депозити до рівня консенсусу, скорочуючи додаткові етапи перевірки, що зменшує час активації валідаторів з приблизно 9 годин до приблизно 13 хвилин.
Покращення масштабованості Layer 2: підвищення пропускної спроможності Blob
EIP-7691: збільшення пропускної здатності Blob
Минулого року оновлення Dencun представило Blobs як ефективний спосіб зберігання даних для Layer 2 rollups. Наразі щодня на Ethereum подається приблизно 21 тисяча Blobs, але ємність вже близька до межі, що призводить до зростання витрат і обмежує пропускну здатність.
На даний момент цільова кількість Blob для кожного блоку Ethereum становить 3, максимальна — 6. EIP-7691 пропонує підвищити цільове значення до 6, а максимальне — до 9, щоб збільшити ємність зберігання даних, підвищити пропускну здатність і масштабованість. Це знизить витрати на зберігання даних, що, в свою чергу, зменшить витрати на транзакції L2.
EIP-7623: підвищення вартості calldata
Перед впровадженням механізму Blob, L2 в основному використовував calldata для зберігання даних, і в деяких випадках все ще продовжує його використовувати, оскільки це може бути більш економічно вигідно.
EIP-7623 підвищує витрати на calldata, щоб стимулювати основне використання blob для зберігання даних в L2, що дозволяє підвищити ефективність транзакцій rollup.
Покращення користувацького досвіду (UX)
EIP-7702: встановлення коду EOA рахунку
Ключова ідея: тимчасове надання EOA можливостей смарт-контракту
EIP-7702 вводить новий тип транзакцій (ідентифікатор 0x04), що дозволяє зовнішнім володіючим рахункам (EOA) тимчасово отримувати функціональність смарт-контракту під час виконання транзакції. Іншими словами, хоча традиційно EOA не має коду і може використовуватися лише для підписання транзакцій, завдяки цій пропозиції EOA може "завантажити" частину коду в рамках однієї транзакції, виконуючи складні операції, як смарт-контрактний гаманець.
Основні переваги
Пакетні операції: Користувачі можуть виконувати кілька операцій в одній транзакції (наприклад, комбінація approve + deposit), що дозволяє уникнути неефективності, пов'язаної з необхідністю виконання кількох транзакцій.
· Газове спонсорство: цей механізм також може підтримувати спонсорство третіх сторін для покриття комісій за транзакції, покращуючи досвід користувачів, дозволяючи їм виконувати операції без попереднього володіння ETH.
· Підвищення безпеки та гнучкості: користувачі можуть здійснювати детальний контроль за правами доступу до угод, наприклад, дозволяти субрахункам діяти лише за певних умов, що підвищує безпеку рахунку.
Можливі виклики
· Проблема екологічної сумісності: оскільки EOA традиційно вважається без коду, деякі існуючі смарт-контракти або перевірки безпеки (наприклад, require(tx.origin == msg.sender)) можуть вимагати коригування, щоб адаптуватися до цього механізму тимчасового надання коду.
· Збільшення складності структури угод: впровадження нових типів угод вимагатиме значних змін у гаманцях і клієнтах, щоб забезпечити відсутність вразливостей безпеки або додаткових високих витрат при обробці нових авторизаційних кортежів та тимчасових налаштувань коду.
EIP-7702 дозволяє звичайним EOA тимчасово отримувати функціональність смарт-контрактів в одній транзакції, що підтримує пакетні транзакції, спонсорування транзакцій та більш гнучке управління правами. Цей механізм може значно покращити користувацький досвід та розширити функції dApp, але також порушить деякі традиційні припущення, які потребують адаптації та оновлення з боку екосистеми. Загалом, це важлива пропозиція, що прокладає шлях для абстракції рахунків, метою якої є зробити майбутні рахунки Ethereum одночасно безпечними та більш гнучкими.
Інші EIP
EIP-7685: Загальний запит виконавчого рівня
Фон та мета
На даний момент між Eth1 (виконавчим шаром) та Beacon Chain (шаром консенсусу) потрібно обробити три основні запити:
Депозит: події депозиту, ініційовані користувачем, спочатку з'являються в блоці Eth1, але в кінцевому підсумку потребують обробки в Beacon Chain.
Виведення: Запити на виведення, що надходять з Beacon Chain (зазвичай через інструменти командного рядка), повинні оброблятися на Eth1.
Злиття валідаторів: Знову ж таки, цей тип запиту потрібно передавати між Eth1 і Beacon Chain.
Чому потрібна ця пропозиція
В даний час різні типи операцій передаються між двома рівнями, що може призвести до плутанини. Єдиний обробний каркас, запропонований EIP-7685, має на меті:
· Використовуйте стандартний метод для обробки всіх цих запитів, щоб процес був більш зрозумілим і ефективним;
· Тільки спираючись на Eth1 для ініціювання цих операцій, можна відокремити середовище роботи валідаторів і управління стейком, що підвищує безпеку.
Основний зміст
Ідентифікатор типу запиту: для кожної операції визначено певний ідентифікатор, наприклад, для вже існуючих типів запитів на депозит і вилучення, тепер потрібно додати тип запиту на об'єднання.
Гарантія цілісності: будуть використовуватися деякі механізми (такі як хешування, мерклева структура даних) для забезпечення цілісності та безпеки запитуваних даних.
Обробка черги та обмеження швидкості: для запитів, що очікують обробки, будуть встановлені певні обмеження (наприклад, кількість одночасно очікуючих запитів на депозит, зняття або об'єднання), щоб запобігти перевантаженню системи.
остаточне значення
Для звичайних користувачів і розробників це означає, що в майбутньому будь-які операції, такі як ініціювання депозитів, виведення коштів або злиття валідаторів, можуть бути виконані швидше та безпечніше через єдиний, стандартизований процес. Це не тільки підвищує ефективність системи, але й допомагає знизити загальний ризик.
EIP-2537: Препроцесор операцій кривої BLS12–381
Основна мета
Ця пропозиція додала в Ethereum вбудовану функцію (звану попередньо скомпільованим контрактом), спеціально призначену для обробки математичних операцій на кривій BLS12–381.
Чому потрібен цей попередньо скомпільований код
· Підвищення ефективності: пряма реалізація складних обчислень еліптичних кривих (таких як перевірка підписів і агрегація) у смарт-контрактах споживає багато газу. Попередньо скомпільовані контракти можуть суттєво знизити вартість цих обчислень.
· Вища безпека: у порівнянні з поточною кривою BN254 (безпека приблизно 80 біт), крива BLS12–381 забезпечує близько 120 біт безпеки, що робить криптографічні операції більш безпечними.
Основне використання
· BLS підпис верифікація: BLS підпис дозволяє об'єднати кілька підписів в один, що значно зменшує обсяг обчислень під час верифікації.
· Перевірка доказів zkSNARK: у деяких рішеннях для захисту конфіденційності та масштабованості необхідно перевіряти докази zkSNARK, які також залежать від складних обчислень еліптичних кривих.
фактичне значення
За допомогою цього EIP розробники можуть більш ефективно та з нижчими витратами використовувати криптографічні обчислення, пов'язані з кривою BLS12–381, у смарт-контрактах, що підтримує більше інноваційних застосувань, таких як більш ефективні механізми консенсусу, міжланцюгові взаємодії та різноманітні децентралізовані застосунки.
Коротко кажучи, EIP-2537 розроблено для вирішення проблеми надмірних витрат газу під час виконання високобезпечних криптографічних обчислень в ланцюгу, роблячи ці складні обчислення більш ефективними та практичними за допомогою попередньо скомпільованих контрактів.
EIP-2935: Збереження історичних хешів блоків у стані
Поточна проблема
У віртуальній машині Ethereum (EVM) за допомогою операційного коду BLOCKHASH можна отримати лише хеші останніх 256 блоків (приблизно за 50 хвилин), що для деяких застосувань недостатньо, наприклад, для крос-ланцюгових застосувань, які потребують підтвердження даних більш ранніх блоків, або безстанційних клієнтів (як rollup).
Ядро пропозиції
EIP-2935 пропонує додатково зберігати 8192 хеші блоків у стані блокчейну (приблизно за 27,3 години), що значно розширює діапазон історичних даних блоків, доступних для запитів.
Як реалізувати
Окрім збереження існуючого операційного коду BLOCKHASH, що може звертатися лише до останніх 256 блоків, пропозиція також введе спеціальний новий системний контракт:
· set() метод: під час обробки кожного блоку новий контракт автоматично зберігатиме хеш поточного блоку в кільцевому буфері.
· get() метод: будь-хто або смарт-контракт можуть використовувати цей метод для запиту історичних хешів блоків, збережених у кільцевому буфері.
фактичні переваги
Таким чином, кросчейн-додатки, rollup або інші системи, які потребують доступу до ранніх блочних даних, можуть безпосередньо отримувати необхідну історичну інформацію в ланцюгу, не покладаючись на зовнішні дані, що робить їхнє проектування простішим, безпечнішим і надійнішим.
EIP-7840: Додавання розкладу blob до конфігурації EL
Основна мета
Ця пропозиція має на меті внести ключові параметри, що стосуються планування blob (наприклад, кількість blob, дозволена в кожному блоці, та пропорція оновлення базового збору), до конфігураційного файлу виконавчого рівня (EL).
Конкретні дії
· Додайте налаштування "Кількість цільових blob" та "Максимальна кількість blob" у файл конфігурації.
· Одночасно додайте параметр під назвою baseFeeUpdateFraction, щоб регулювати швидкість оновлення базового збору.
· Клієнт може запитувати ці параметри через API вузлів, щоб дізнатися про конкретну конфігурацію blob в поточній мережі.
Чому це корисно
Ця інформація може допомогти розробникам і операторам вузлів точніше оцінювати витрати на блоб-газ, а також сприяти кращому управлінню обробкою та плануванням великих даних у блоках мережі.
В цілому, EIP-7840 додає набір конфігурованих параметрів планування blob до виконавчого шару Ethereum, що робить мережу більш ефективною та прозорою при обробці великих даних (blob).
EIP-7549: Переміщення індексу комітету з доказу
Основна ідея
Наразі повідомлення про перевірку голосування (Attestation) містить три частини:
· Голосування LMD GHOST (включаючи корінь блоку та часові слоти)
· Casper-FFG голосування (включаючи source та target)
· Індекс комітету (index)
Проблема в тому, що індекс комітету також підписано, що призводить до того, що навіть якщо зміст голосування однаковий, але через різні індекси генеруються різні корені підпису. Це ускладнює агрегацію голосування з однаковим змістом.
Рішення, запропоноване EIP-7549, полягає в тому, щоб видалити індекс комітету з підписаного повідомлення про голосування. Таким чином, лише основний зміст голосування (голосування LMD GHOST та Casper-FFG) братиме участь у обчисленні підпису, що дозволяє кільком валідаторам одного й того ж голосування генерувати однаковий корінь підпису, що дозволяє їх об'єднувати.
Основні переваги
· Значне зменшення обсягу роботи з верифікації: у поточних умовах, щоб досягти 2/3 консенсусу, може знадобитися верифікувати 1366 голосів. Після видалення індексу комітету потрібно перевірити лише близько 22 голосів (економія приблизно 62 рази за обсягом обчислень), що є надзвичайно значним покращенням ефективності для процесу верифікації, який вимагає великої кількості парних обчислень, особливо для клієнтів Casper FFG на основі нульових знань.
· Підвищення ефективності зберігання даних в блокчейні: завдяки більш ефективній агрегації інформації про голосування, можливо упакувати більше голосів в кожен блок. Тепер один блок може містити лише голоси з 2-х часових проміжків, після вдосконалення їх може бути до 8-ми часових проміжків, навіть якщо онлайн лише 1/8 пропозицій, всі голоси можуть бути включені в блок.
Видалення індексу комітету з повідомлення Attestation не лише може значно зменшити кількість парних обчислень, які потрібно обробляти під час валідації голосів, але й дозволяє ефективніше упакувати дані голосування, підвищуючи продуктивність усього процесу валідації консенсусу та використання зберігання в ланцюгу. Це покращення є особливо важливим для механізму консенсусу Casper FFG та його пов'язаних перевірок нульових знань.
Висновок
Pectra, як оновлення, що охоплює рекордну кількість EIP, сприятиме розвитку Ethereum у ключових напрямках, таких як абстракція облікових записів, оптимізація механізму валідаторів, підвищення ефективності мережі та розширення Layer 2. Також, як нещодавно підкреслив Віталік Бутерін, хоча Ethereum використовує розширення на основі Rollup, він все ще продовжує оптимізувати Layer 1, наприклад, нещодавно підвищивши обмеження Gas до 36 мільйонів, а в майбутньому може ще більше підвищити стійкість до цензури, пропускну здатність та масштабованість.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ознайомтеся з оновленням Ethereum Pectra: повний аналіз всіх EIP
Автор | Танай Вед, Coin Metrics
Компілірувати | GaryMa У Гу сказав Блокчейн
Окрім перекладу оригіналу, ця стаття також доповнює описом інших EIP Pectra, які не були згадані в оригіналі.
Оригінальне посилання:
Ключові моменти
Pectra є наступним великим оновленням Ethereum, яке включає зміни в шарі виконання (Prague) та шарі консенсусу (Electra). Після численних труднощів з оновленням тестової мережі Pectra, остаточно було вирішено активувати оновлення основної мережі Pectra о 10:05 UTC 7 травня.
Це оновлення забезпечить ключові поліпшення для стейкінгу, масштабованості Layer 2 та користувацького досвіду (UX), закладаючи основу для майбутніх трансформацій.
Основні зміни включають: підвищення ліміту стейкінгу для валідаторів, гнучке виведення стейків, покращення абстракції облікових записів та збільшення пропускної здатності blob для підвищення ефективності та безпеки мережі.
Вступ
Від «Злиття» (The Merge) минуло 31 місяць, від оновлення «Shapella» — 24 місяці, від оновлення «Dencun» — 13 місяців, Ethereum незабаром зустріне наступне велике оновлення — жорсткий форк Pectra.
А до оновлення тестової мережі Pectra перед оновленням основної мережі були численні перешкоди.
Оновлення Pectra тестової мережі Holesky було активовано 24 лютого о 21:55 UTC, проте через помилку конфігурації програмного забезпечення клієнта (помилкові адреси контрактів депозитів Geth, Nethermind та Besu) воно було перервано, що призвело до розгалуження мережі. Розробники обговорили план відновлення мережі через масові штрафні події, спрямовані на прискорення виходу помилкових валідаторів та досягнення остаточності мережі, яка зможе бути реалізована лише до 11 березня.
Оновлення Pectra тестової мережі Sepolia відбулося 5 березня згідно з планом. Через проблеми з налаштуваннями контракту на депозит частина клієнтів виконавчого рівня (EL) мала проблеми з включенням транзакцій у блоки, але проблема швидко була вирішена, і мережа досягла фіналізації.
19 березня, для тестування виходу валідаторів, був запущений новий тестовий мережевий Hoodi, і 26 березня успішно активовано оновлення мережі Pectra.
Оновлення тестової мережі Ethereum Pectra пройшло через двомісячні труднощі, прокладаючи шлях для розгортання основної мережі, остаточно заплановано на активацію оновлення основної мережі Pectra приблизно о 10:05 UTC 7 травня.
Як і в попередніх оновленнях Ethereum, Pectra охоплює як шар виконання (EL), так і шар консенсусу (CL). Його назва відображає цей подвійний акцент: Prague (Прага) представляє оновлення шару виконання на честь місця проведення Devcon 4; Electra (Електра) символізує оновлення шару консенсусу.
Pectra є одним з найбільших хардфорків в історії Ethereum, що стосується найбільшої кількості EIP (Ethereum Improvement Proposals, пропозицій з покращення Ethereum) — 11 EIP. Він подальше оптимізує на основі оновлення Dencun минулого року, з метою покращення користувацького досвіду (UX), оптимізації роботи валідаторів та сприяння розширенню Layer 2, що, як очікується, матиме глибокий вплив на екосистему Ethereum.
У цій статті ми класифікуємо та аналізуємо різні EIP відповідно до їхніх областей.
Покращення механізму валідаторів та стекингу
Pectra оптимізує досвід роботи валідаторів у системі PoS Ethereum за допомогою трьох основних EIP:
EIP-7251: підвищення максимальної ефективної балансу (MaxEB)
На даний момент механізм стейкінгу Ethereum обмежує максимальну ефективну ставку для одного валідатора до 32 ETH, що означає, що незалежні стейкери повинні ставити по 32 ETH, а винагорода за ставку, що перевищує цей ліміт, не враховується в ефективній ставці.
EIP-7251 пропонує підвищити максимальний ефективний баланс (MaxEB) до 2048 ETH, дозволяючи діапазон стейкінгу одного валідатора розширитися до 32 до 2048 ETH, що призведе до таких наслідків:
· Підвищення гнучкості стейкінгу: стейкери можуть реінвестувати всі доходи в ефективний стейкінг-баланс, без обмеження на кратність 32 ETH. Наприклад, валідатор, який має 33 ETH, тепер може отримувати прибуток від усіх 33 ETH, підвищуючи ефективність і гнучкість капіталу.
· Зменшення кількості валідаторів: наразі в Ethereum налічується 1,05 мільйона активних валідаторів, цей EIP дозволяє великим операторам об'єднувати своїх валідаторів, що дозволяє зменшити загальну кількість та полегшити навантаження на мережу.
· Зниження навантаження на мережу: хоча більша кількість валідаторів сприяє децентралізації, це також збільшує навантаження на пропускну здатність і обчислення. Підвищення MaxEB може оптимізувати набір валідаторів та зменшити витрати на точкову комунікацію.
EIP-7002: Виконувальний рівень може ініціювати зняття
EIP-7002 подальше удосконалює функції валідаторів, дозволяючи їм безпосередньо ініціювати вихід та часткові зняття через виконавчий рівень (0x01) за допомогою підтвердження зняття.
На даний момент у валідаторів є два ключі:
Активний ключ, який використовується для виконання обов'язків з перевірки;
Ключ для виведення, що використовується для доступу та управління коштами, що знаходяться в ставці.
Раніше лише активні ключі могли ініціювати вихід, тоді як ключі для зняття не могли діяти самостійно. EIP-7002 дозволяє також ключам для зняття ініціювати зняття, що призводить до:
· Більший контроль над фінансами: валідатори можуть безпосередньо керувати коштами, не покладаючись на операторів вузлів.
· Підтримка повністю бездоказових пулів для стейкінгу, що підвищує безпеку та рівень децентралізації.
EIP-6110: зберігання депозитів валідаторів в блокчейні
Наразі, коли нові валідатори вносять депозит на виконавчому рівні, їм потрібно чекати, поки рівень консенсусу ідентифікує та обробить це, що призводить до затримки активації.
EIP-6110 дозволяє виконавчому рівню безпосередньо передавати інформацію про депозити до рівня консенсусу, скорочуючи додаткові етапи перевірки, що зменшує час активації валідаторів з приблизно 9 годин до приблизно 13 хвилин.
Покращення масштабованості Layer 2: підвищення пропускної спроможності Blob
EIP-7691: збільшення пропускної здатності Blob
Минулого року оновлення Dencun представило Blobs як ефективний спосіб зберігання даних для Layer 2 rollups. Наразі щодня на Ethereum подається приблизно 21 тисяча Blobs, але ємність вже близька до межі, що призводить до зростання витрат і обмежує пропускну здатність.
На даний момент цільова кількість Blob для кожного блоку Ethereum становить 3, максимальна — 6. EIP-7691 пропонує підвищити цільове значення до 6, а максимальне — до 9, щоб збільшити ємність зберігання даних, підвищити пропускну здатність і масштабованість. Це знизить витрати на зберігання даних, що, в свою чергу, зменшить витрати на транзакції L2.
EIP-7623: підвищення вартості calldata
Перед впровадженням механізму Blob, L2 в основному використовував calldata для зберігання даних, і в деяких випадках все ще продовжує його використовувати, оскільки це може бути більш економічно вигідно.
EIP-7623 підвищує витрати на calldata, щоб стимулювати основне використання blob для зберігання даних в L2, що дозволяє підвищити ефективність транзакцій rollup.
Покращення користувацького досвіду (UX)
EIP-7702: встановлення коду EOA рахунку
Ключова ідея: тимчасове надання EOA можливостей смарт-контракту
EIP-7702 вводить новий тип транзакцій (ідентифікатор 0x04), що дозволяє зовнішнім володіючим рахункам (EOA) тимчасово отримувати функціональність смарт-контракту під час виконання транзакції. Іншими словами, хоча традиційно EOA не має коду і може використовуватися лише для підписання транзакцій, завдяки цій пропозиції EOA може "завантажити" частину коду в рамках однієї транзакції, виконуючи складні операції, як смарт-контрактний гаманець.
Основні переваги
· Газове спонсорство: цей механізм також може підтримувати спонсорство третіх сторін для покриття комісій за транзакції, покращуючи досвід користувачів, дозволяючи їм виконувати операції без попереднього володіння ETH.
· Підвищення безпеки та гнучкості: користувачі можуть здійснювати детальний контроль за правами доступу до угод, наприклад, дозволяти субрахункам діяти лише за певних умов, що підвищує безпеку рахунку.
Можливі виклики
· Проблема екологічної сумісності: оскільки EOA традиційно вважається без коду, деякі існуючі смарт-контракти або перевірки безпеки (наприклад, require(tx.origin == msg.sender)) можуть вимагати коригування, щоб адаптуватися до цього механізму тимчасового надання коду.
· Збільшення складності структури угод: впровадження нових типів угод вимагатиме значних змін у гаманцях і клієнтах, щоб забезпечити відсутність вразливостей безпеки або додаткових високих витрат при обробці нових авторизаційних кортежів та тимчасових налаштувань коду.
EIP-7702 дозволяє звичайним EOA тимчасово отримувати функціональність смарт-контрактів в одній транзакції, що підтримує пакетні транзакції, спонсорування транзакцій та більш гнучке управління правами. Цей механізм може значно покращити користувацький досвід та розширити функції dApp, але також порушить деякі традиційні припущення, які потребують адаптації та оновлення з боку екосистеми. Загалом, це важлива пропозиція, що прокладає шлях для абстракції рахунків, метою якої є зробити майбутні рахунки Ethereum одночасно безпечними та більш гнучкими.
Інші EIP
EIP-7685: Загальний запит виконавчого рівня
Фон та мета
На даний момент між Eth1 (виконавчим шаром) та Beacon Chain (шаром консенсусу) потрібно обробити три основні запити:
Депозит: події депозиту, ініційовані користувачем, спочатку з'являються в блоці Eth1, але в кінцевому підсумку потребують обробки в Beacon Chain.
Виведення: Запити на виведення, що надходять з Beacon Chain (зазвичай через інструменти командного рядка), повинні оброблятися на Eth1.
Злиття валідаторів: Знову ж таки, цей тип запиту потрібно передавати між Eth1 і Beacon Chain.
Чому потрібна ця пропозиція
В даний час різні типи операцій передаються між двома рівнями, що може призвести до плутанини. Єдиний обробний каркас, запропонований EIP-7685, має на меті:
· Використовуйте стандартний метод для обробки всіх цих запитів, щоб процес був більш зрозумілим і ефективним;
· Тільки спираючись на Eth1 для ініціювання цих операцій, можна відокремити середовище роботи валідаторів і управління стейком, що підвищує безпеку.
Основний зміст
Ідентифікатор типу запиту: для кожної операції визначено певний ідентифікатор, наприклад, для вже існуючих типів запитів на депозит і вилучення, тепер потрібно додати тип запиту на об'єднання.
Гарантія цілісності: будуть використовуватися деякі механізми (такі як хешування, мерклева структура даних) для забезпечення цілісності та безпеки запитуваних даних.
Обробка черги та обмеження швидкості: для запитів, що очікують обробки, будуть встановлені певні обмеження (наприклад, кількість одночасно очікуючих запитів на депозит, зняття або об'єднання), щоб запобігти перевантаженню системи.
остаточне значення
Для звичайних користувачів і розробників це означає, що в майбутньому будь-які операції, такі як ініціювання депозитів, виведення коштів або злиття валідаторів, можуть бути виконані швидше та безпечніше через єдиний, стандартизований процес. Це не тільки підвищує ефективність системи, але й допомагає знизити загальний ризик.
EIP-2537: Препроцесор операцій кривої BLS12–381
Основна мета
Ця пропозиція додала в Ethereum вбудовану функцію (звану попередньо скомпільованим контрактом), спеціально призначену для обробки математичних операцій на кривій BLS12–381.
Чому потрібен цей попередньо скомпільований код
· Підвищення ефективності: пряма реалізація складних обчислень еліптичних кривих (таких як перевірка підписів і агрегація) у смарт-контрактах споживає багато газу. Попередньо скомпільовані контракти можуть суттєво знизити вартість цих обчислень.
· Вища безпека: у порівнянні з поточною кривою BN254 (безпека приблизно 80 біт), крива BLS12–381 забезпечує близько 120 біт безпеки, що робить криптографічні операції більш безпечними.
Основне використання
· BLS підпис верифікація: BLS підпис дозволяє об'єднати кілька підписів в один, що значно зменшує обсяг обчислень під час верифікації.
· Перевірка доказів zkSNARK: у деяких рішеннях для захисту конфіденційності та масштабованості необхідно перевіряти докази zkSNARK, які також залежать від складних обчислень еліптичних кривих.
фактичне значення
За допомогою цього EIP розробники можуть більш ефективно та з нижчими витратами використовувати криптографічні обчислення, пов'язані з кривою BLS12–381, у смарт-контрактах, що підтримує більше інноваційних застосувань, таких як більш ефективні механізми консенсусу, міжланцюгові взаємодії та різноманітні децентралізовані застосунки.
Коротко кажучи, EIP-2537 розроблено для вирішення проблеми надмірних витрат газу під час виконання високобезпечних криптографічних обчислень в ланцюгу, роблячи ці складні обчислення більш ефективними та практичними за допомогою попередньо скомпільованих контрактів.
EIP-2935: Збереження історичних хешів блоків у стані
Поточна проблема
У віртуальній машині Ethereum (EVM) за допомогою операційного коду BLOCKHASH можна отримати лише хеші останніх 256 блоків (приблизно за 50 хвилин), що для деяких застосувань недостатньо, наприклад, для крос-ланцюгових застосувань, які потребують підтвердження даних більш ранніх блоків, або безстанційних клієнтів (як rollup).
Ядро пропозиції
EIP-2935 пропонує додатково зберігати 8192 хеші блоків у стані блокчейну (приблизно за 27,3 години), що значно розширює діапазон історичних даних блоків, доступних для запитів.
Як реалізувати
Окрім збереження існуючого операційного коду BLOCKHASH, що може звертатися лише до останніх 256 блоків, пропозиція також введе спеціальний новий системний контракт:
· set() метод: під час обробки кожного блоку новий контракт автоматично зберігатиме хеш поточного блоку в кільцевому буфері.
· get() метод: будь-хто або смарт-контракт можуть використовувати цей метод для запиту історичних хешів блоків, збережених у кільцевому буфері.
фактичні переваги
Таким чином, кросчейн-додатки, rollup або інші системи, які потребують доступу до ранніх блочних даних, можуть безпосередньо отримувати необхідну історичну інформацію в ланцюгу, не покладаючись на зовнішні дані, що робить їхнє проектування простішим, безпечнішим і надійнішим.
EIP-7840: Додавання розкладу blob до конфігурації EL
Основна мета
Ця пропозиція має на меті внести ключові параметри, що стосуються планування blob (наприклад, кількість blob, дозволена в кожному блоці, та пропорція оновлення базового збору), до конфігураційного файлу виконавчого рівня (EL).
Конкретні дії
· Додайте налаштування "Кількість цільових blob" та "Максимальна кількість blob" у файл конфігурації.
· Одночасно додайте параметр під назвою baseFeeUpdateFraction, щоб регулювати швидкість оновлення базового збору.
· Клієнт може запитувати ці параметри через API вузлів, щоб дізнатися про конкретну конфігурацію blob в поточній мережі.
Чому це корисно
Ця інформація може допомогти розробникам і операторам вузлів точніше оцінювати витрати на блоб-газ, а також сприяти кращому управлінню обробкою та плануванням великих даних у блоках мережі.
В цілому, EIP-7840 додає набір конфігурованих параметрів планування blob до виконавчого шару Ethereum, що робить мережу більш ефективною та прозорою при обробці великих даних (blob).
EIP-7549: Переміщення індексу комітету з доказу
Основна ідея
Наразі повідомлення про перевірку голосування (Attestation) містить три частини:
· Голосування LMD GHOST (включаючи корінь блоку та часові слоти)
· Casper-FFG голосування (включаючи source та target)
· Індекс комітету (index)
Проблема в тому, що індекс комітету також підписано, що призводить до того, що навіть якщо зміст голосування однаковий, але через різні індекси генеруються різні корені підпису. Це ускладнює агрегацію голосування з однаковим змістом.
Рішення, запропоноване EIP-7549, полягає в тому, щоб видалити індекс комітету з підписаного повідомлення про голосування. Таким чином, лише основний зміст голосування (голосування LMD GHOST та Casper-FFG) братиме участь у обчисленні підпису, що дозволяє кільком валідаторам одного й того ж голосування генерувати однаковий корінь підпису, що дозволяє їх об'єднувати.
Основні переваги
· Значне зменшення обсягу роботи з верифікації: у поточних умовах, щоб досягти 2/3 консенсусу, може знадобитися верифікувати 1366 голосів. Після видалення індексу комітету потрібно перевірити лише близько 22 голосів (економія приблизно 62 рази за обсягом обчислень), що є надзвичайно значним покращенням ефективності для процесу верифікації, який вимагає великої кількості парних обчислень, особливо для клієнтів Casper FFG на основі нульових знань.
· Підвищення ефективності зберігання даних в блокчейні: завдяки більш ефективній агрегації інформації про голосування, можливо упакувати більше голосів в кожен блок. Тепер один блок може містити лише голоси з 2-х часових проміжків, після вдосконалення їх може бути до 8-ми часових проміжків, навіть якщо онлайн лише 1/8 пропозицій, всі голоси можуть бути включені в блок.
Видалення індексу комітету з повідомлення Attestation не лише може значно зменшити кількість парних обчислень, які потрібно обробляти під час валідації голосів, але й дозволяє ефективніше упакувати дані голосування, підвищуючи продуктивність усього процесу валідації консенсусу та використання зберігання в ланцюгу. Це покращення є особливо важливим для механізму консенсусу Casper FFG та його пов'язаних перевірок нульових знань.
Висновок
Pectra, як оновлення, що охоплює рекордну кількість EIP, сприятиме розвитку Ethereum у ключових напрямках, таких як абстракція облікових записів, оптимізація механізму валідаторів, підвищення ефективності мережі та розширення Layer 2. Також, як нещодавно підкреслив Віталік Бутерін, хоча Ethereum використовує розширення на основі Rollup, він все ще продовжує оптимізувати Layer 1, наприклад, нещодавно підвищивши обмеження Gas до 36 мільйонів, а в майбутньому може ще більше підвищити стійкість до цензури, пропускну здатність та масштабованість.
Посилання для довідки: