Прогнозується, що хардфорк Pectra стартує в мережевому розгортанні у березні 2025 року. Оновлення Pectra містить 11 технічних пакетів (EIP), які включають:
EIP-2537: Попереднє компілювання операцій на кривій BLS12-381
EIP-2935: Зберігання історичних хешів блоків в стані
EIP-6110: надання ланцюжкових депозитів валідатора
EIP-7002: Виконавчий шар спричинює вихід
EIP-7251: додайте MAX_EFFECTIVE_BALANCE
EIP-7549: перенос індексу комітету за межі підтвердження
EIP-7623: Додати вартість calldata
EIP-7685: Запит загального виконавчого рівня
EIP-7691: Збільшення пропускної здатності Blob
EIP-7702: Установіть код облікового запису EOA
EIP-7840: Додайте план Blob до файлу конфігурації EL
Технічні протоколи стосовно застави
EIP-6110: Попередня компіляція операцій на кривій BLS12-381
Спростіть процес обробки для участі користувачів у стейкінгу, щоб час очікування значно скоротився.
Спосіб участі користувачів у стейкінгу полягає в тому, щоб внести 32 ETH на рівень виконання та записати це журналом подій, а потім рівень консенсусу виконує аналіз журналу подій, щоб визначити, чи бере хтось участь у стейкінгу, а потім користувач, який бере участь у стейкінгу, стає валідатором.
Проте перш за все, валідатори на рівні консенсусу повинні спочатку визначити часову точку для досягнення консенсусу, інакше вони виявлять, що деякі валідатори бачать 5 нових внесків, тоді як інші бачать тільки 3, тому валідатори рівня консенсусу будуть голосувати за блок виконання (eth1data), на який слід посилатися, щоб забезпечити, що всі бачать однаковий блок виконання.
Проте під час початкового проектування для уникнення серйозних помилок на рівні виконання, які можуть призвести до роздвоєння ланцюжків, використовується блок виконання (eth1data), який був створений близько 10 годин тому, щоб забезпечити розробникам консенсусу достатньо часу на реагування та вирішення проблем у випадку серйозних помилок. Однак це також означає, що найшвидший час для активації ставок на участь - це близько 10 годин.
!
△ 10900000 eth1data в блоці CL, записаний в ньому Block Hash - це 21683339 блоку виконавчого шару, який з'явився 10 годин тому.
Після виконання технічного протоколу EIP-6110 дані зобов'язання користувача за контрактом безпосередньо стануть частиною рівня виконання, і оскільки сам блок рівня консенсусу міститиме блок виконавчого рівня (але не eth1data), валідаторам рівня консенсусу більше не потрібно розглядати проблему «підтвердження того, що блок пам'яті еталонного рівня виконання однаковий», доки за блок пам'яті консенсусного рівня проголосують понад дві третини валідаторів, усі досягнуть консенсусу щодо одного блоку рівня виконання. Таким чином, після участі в заставі користувач може дочекатися, поки блок пам'яті виконавчого рівня завершить обробку не раніше ніж за 13 хвилин, а клієнт рівня консенсусу також може видалити складну логіку, яка спочатку використовувалася для обробки даних стейкінгу.
EIP-7002: Зберігання значень хеш-блоків історії в State
Дозволяє вдосконалити процес виходу валідатора з застави або вилучення застави та доходу, знизити ризики валідатора.
Для участі в заставі потрібно мати два ключі: ключ валідатора та ключ виведення.
Ключ валідатора використовується для робочого вмісту валідатора, а облікові дані для виведення коштів використовуються для адреси, на яку буде виведено депозит і заробіток, коли валідатор вийде зі стейкінгу.
Якщо ви втратите ключ валідатора, ви не зможете виконувати функції валідатора та вилучити заставу; якщо ви втратите підтвердження виведення, ви втратите всі ставки та прибутки. Крім того, деякі користувачі використовують сторонні послуги застави, такі як Lido; коли вони використовують ці платформи, користувачам потрібно самостійно зберігати підтвердження виведення, тоді як ключ валідатора зберігається та виконує функції валідатора за допомогою постачальника послуг.
За допомогою технічного протоколу EIP-7002 користувач може викликати «Зняття контракту» (тобто розгорнутого на 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) за допомогою Відкликання облікових даних, щоб вийти з застави (Вихід) або зняти заставу та прибуток (Часткове зняття), що дозволить знизити можливі ризики, пов'язані з використанням послуг сторонньої застави. Якщо користувач самостійно бере участь у заставі, але втратив Ключ валідатора, він також може вийти з застави за допомогою цього.
Параметри запиту містять validator_pubkey та amount: validator_pubkey - це публічний ключ валідатора, amount - це сума, яку потрібно вивести.
Креденціал виведення, що ініціює запит, повинен бути креденціалом виведення перевіряючого ключа валідатора.
При виклику контракту зняття для ініціювання запиту слід додати плату за газ (ETH), плата за газ обчислюється відповідно до поточної кількості запитів на виведення, якщо кількість запитів велика, плата за газ зростатиме.
Якщо обліковий запис на виведення користувача є угодою, то можна спочатку отримати поточну вартість оплати за обробку, витягнувши угоду про виведення, а потім надіслати запит і додати оплату за обробку; але якщо обліковий запис на виведення є обліковим записом EOA, то неможливо отримати точний розмір оплати за обробку, можна лише заздалегідь підрахувати в ланцюжку та сплатити надмірну оплату за обробку (не повертається), щоб гарантувати успішне надсилання запиту.
Примітка: якщо ваша Withdrawal Credential все ще у форматі BLS публічного ключа, не забудьте спочатку переключитися і перетворити його у формат EL-адреси.
EIP-7251: додайте MAX_EFFECTIVE_BALANCE
Збільшення максимального обсягу застави значно скорочує кількість валідаторів, і ті валідатори, які не досягли максимального рівня, можуть автоматично отримувати дохід від застави.
Користувачі, які забезпечують ставку, повинні надати MAX_EFFECTIVE_BALANCE ETH у кількості, яка не може бути ні менше, ні більше (наразі MAX_EFFECTIVE_BALANCE складає 32 ETH). Якщо користувач має 1024 ETH для ставки, він може прийняти участь у 32 ставках, активувати 32 валідатори, виконувати 32 вузли валідатора. Активна участь у ставці призвела до того, що наразі вже близько 1 мільйона валідаторів та постійне збільшення, що призвело до того, що дані стану на рівні згоди стали більшими, що вимагає більшого навантаження на рівні p2p мережі консенсусу, оскільки кожен слот (кожні 12 секунд) вимагає безперервного передавання та агрегування підписів великої кількості валідаторів на рівні p2p мережі.
Після впровадження технічного протоколу EIP-7251 мінімальний ліміт стейкінгу (MIN_ACTIVATION_BALANCE) все ще становить 32 ETH, але верхня межа (MAX_EFFECTIVE_BALANCE) буде значно збільшена до 2048 ETH, ви можете здійснювати стейкінг будь-якої суми ETH між 32~2048, ви можете отримувати винагороду за стейкінг, більше не потрібно регулярно виводити дохід і продовжувати робити ставки на нові ETH після накопичення 32 ETH.
Наразі існуючим валідаторам не потрібно спеціально вийти зі ставки перед поєднанням знову долучитися до ставки, а можна безпосередньо використовувати новий «контракт для об'єднання депозитів на виконавчому рівні» (розгорнутий на 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), щоб валідатор за допомогою його виведення грошових коштів звернувся до контракту з проханням про початок процедури об'єднання депозитів.
Параметри запиту на об'єднання депозиту містять source_pubkey та target_pubkey: обидва ці ключі є ключами перевірки валідатора, де source валідатор буде об'єднаний з target валідатором.
Запитуваний відтягнення повинно бути відтягненням джерела перевірки.
При виклику договору про злиття для ініціювання запиту буде прикріплена комісія (ETH), і комісія буде розраховуватися відповідно до поточної кількості запитів, якщо кількість запитів велика, комісія збільшиться.
Якщо облікові дані користувача для виведення коштів є контрактом, ви можете зателефонувати до договору про злиття депозиту, щоб отримати поточну суму комісії, а потім ініціювати запит і прикріпити комісію; Однак, якщо облікові дані для виведення коштів є обліковим записом EOA, немає способу отримати точну комісію, тому ви можете лише заздалегідь змоделювати офчейн і сплатити надмірну комісію (яка не буде повернута), щоб гарантувати, що запит буде успішно виконано.
Примітка: Якщо ваші облікові дані для виведення коштів мають формат відкритого ключа BLS, вам потрібно спочатку переключити їх на формат адреси EL.
EIP-7685: Загальний запит рівня виконання
CL, щоб користувачі та служби стейкингу могли безпосередньо надсилати запити на рівень консенсусу.
Користувачі можуть надсилати запити безпосередньо з рівня виконання на рівень консенсусу, а сервіси стейкінгу (наприклад, Lido) можуть працювати більш децентралізовано. Наприклад, запит EIP-7002 на зняття стейкінгу та запит EIP-7251 на об'єднання депозитів. Без цього технічного протоколу користувачам Lido довелося б довіряти постачальнику послуг вузлів Lido виконання депозиту без стейкінгу або злиття на рівні консенсусу. За допомогою цього технічного протоколу користувачі Lido можуть надсилати запити безпосередньо через контракт управління на рівні виконання.
Ці запити будуть відрізнятися типом запиту, щоб розрізняти різні типи запитів, а також для того, щоб відправляти запити через різні контракти, нарешті, ці запити будуть записані в блок пам'яті виконавчого рівня, тому шар консенсусу може безпосередньо отримувати цю інформацію через блок пам'яті виконавчого рівня, не потрібно більше писати окрему логіку розбору.
EIP-6110, EIP-7002 та EIP-7251 - всі вони розроблені на основі стандарту, визначеного в EIP-7685, для формування запитів:
EIP-6110 Додати запит на стейкінг: Тип запиту=0, через Депозитний договір
Технічні протоколи для покращення користувацького досвіду
EIP-7702: Встановлення коду облікового запису EOA
Дозволяє обліковий запис EOA будь-яким чином перевтілюватися в обліковий запис контракту, що значно підвищує зручність використання.
Обліковий запис EOA має деякі недоліки використання, включаючи:
Необхідно записувати та зберігати приватний ключ або мнемонічну фразу, а поріг реєстрації нового користувача високий.
Обліковий запис EOA може виконати лише одну операцію за одну угоду, наприклад, для обміну USDT на ETH на Uniswap, спочатку потрібно запровадити угоду з підтвердженням USDT, а потім виконати іншу угоду для обміну.
Неможливо деталізувати контроль дозволів, схоже на те, що деякі операції з обліковими записами передаються третій стороні для виконання, користувачеві потрібно особисто вирішувати кожну справу, і кожну операцію потрібно підписати та відправити транзакцію раз.
Відсутня система відновлення, ви можете лише самостійно зберігати приватний ключ або мнемонічні слова, якщо вони втрачені, ви не зможете повернути активи на свій рахунок.
Якщо це розумний контракт (наприклад, Safe), то всі вищезазначені проблеми можуть бути вирішені:
Користувачі можуть використовувати приватний ключ у чіпі безпеки мобільного телефону (або комп'ютера) для підписання авторизації, не потрібно запам'ятовувати будь-який приватний ключ або мнемонічні слова, використовувати електронну пошту для підписання авторизації, або інші різні способи авторизації.
Можна об'єднати кілька операцій в одну операцію в межах однієї угоди, тепер складні операції DApp можуть бути виконані лише з одним підписом авторизації та однією угодою.
Можна мати дуже деталізований контроль доступу, користувачі можуть надати дозвіл третій стороні на контроль свого облікового запису, але водночас вказати «з якими контрактами можна взаємодіяти», «які операції заборонені», «скільки коштів може бути витрачено максимально при переказі активів» або «не більше як кілька операцій на тиждень» тощо обмеження.
Ви можете додати механізм відновлення, а також можете перенести активи облікового запису на новий рахунок через механізм відновлення при втраті мнемонічної фрази або мобільного телефону чи електронної пошти.
Пропозиція EIP-7702 надає обліковим записам EOA можливість ставати контрактними рахунками. Користувач підписує перетворене повідомлення закритим ключем EOA, який включає «Chain ID», «Змінену адресу контракту» та «EOA Nonce Value»:
Ідентифікатор ланцюга: використовується для запобігання повторному відтворенню підпису ланцюга A ланцюгом B. Однак, якщо для ідентифікатора ланцюга встановлено значення 0, це означає, що ви готові трансформуватися в кожен ланцюг.
Адреса контракту, в яку ви хочете перетворитися: якщо ви вказали адресу безпеки, ваш обліковий запис EOA стане обліковим записом безпеки; якщо ви вказали порожню адресу (адресу (0)), це означає відміну змін і повернення до простого облікового запису EOA.
Значення Nonce для EOA: використовується для запобігання повторного використання підпису. Якщо значення Nonce збільшується, підпис стає недійсним.
Проте є кілька моментів, на які варто звернути увагу:
Закритий ключ EOA можна продовжувати використовувати
Навіть якщо обліковий запис EOA користувача стає контрактом, він може продовжувати використовувати його так само, як і початковий обліковий запис EOA. Наприклад, якщо ваш обліковий запис EOA стає безпечним контрактом, ви можете використовувати безпечний інтерфейс, пройти процес безпечної транзакції або продовжувати підписувати та надсилати транзакції за допомогою оригінального гаманця EOA. Однак це також означає, що безпека облікового запису, як і раніше, обмежена приватним ключем.
Залишається безпека приватного ключа EOA
Навіть якщо обліковий запис користувача EOA перетвориться на багато підписів, поки він не втратить приватний ключ EOA, безпека його облікового запису завжди буде залежати від безпеки приватного ключа EOA: він все ще повинен добре зберігати свій приватний ключ або фразу для відновлення, тому його обліковий запис не стане таким же безпечним, як багато підписів.
Сховище облікового запису EOA не відформатовано
Коли обліковий запис EOA перетворюється на контракт та записує дані у свій сховище, ці дані, записані в сховище, не форматуються через зміну облікового запису EOA на інший контракт або скасування перетворення, якщо явно не виконується дія видалення даних, тому розробникам слід уникати читання даних, залишених попереднім контрактом, у сховищі, можна звернутися до ERC-7201.
Процес EIP-7702 не включає ініціалізацію
Зазвичай для контрактів необхідний ініціалізаційний крок, під час розгортання контракту синхронно записати інформацію власника контракту (наприклад, публічний ключ або адресу), щоб уникнути втрати права власності над контрактом через вибірковий запуск (Frontrun). Зазвичай це виконується фабричним контрактом, що розгортає контракт, але через те, що EIP-7702 змінюється безпосередньо, а не через одну фабрику, щоб розгорнути контракт на EOA, злочинець може скопіювати підпис користувача та передати транзакцію на ланцюжок, щоб замінити користувача, але ініціалізувати контракт так, щоб його можна було контролювати злочинцю, тому розробникам потрібно бути обережними з EIP-7702. Можливі заходи захисту, такі як перевірка підпису облікового запису EOA в середині ініціалізаційної функції, навіть якщо вас випередять, злочинець не зможе згенерувати підпис цього облікового запису EOA для завершення ініціалізації.
Запити на зміну гейткіпера гаманця
Гаманець повинен добре перевірити користувача, зупинити запит і попередити користувача, коли шкідливий веб-сайт DApp попросить користувача підписати транзакцію трансформації, інакше, якщо користувач підпише шкідливу транзакцію трансформації, активи будуть миттєво переміщені. Ось кілька прикладів того, як трансформуватися в договір:
Модифікований обліковий запис Safe Ithaca
Рахунок Ітака
Технічний протокол DApp
EIP-2537: Попередня компіляція операцій з кривою BLS12-381
Зменште вартість і зробіть його більш придатним для додатків доказу з нульовим розголошенням на основі кривої BLS.
EIP-2537 додає кілька нових контрактів попередньої компіляції для забезпечення недорогих операцій з кривими BLS, що робить більш можливим розробку додатків для доведення з нульовим розголошенням на основі кривих BLS.
EIP-2935: Збереження хешів історичних блоків у стані
Він дозволяє розробникам або вузлам зчитувати хеш блоків минулих блоків пам'яті безпосередньо зі сховища системного контракту.
Якщо розробнику потрібно довести вміст попереднього блоку пам'яті, наприклад, якщо шахрайський челендж Optimismtic Rollup хоче довести, що транзакція існує в 1000 попередніх блоках пам'яті, претендент не може сказати про це прямо.
«Будь ласка, вірте мені, що ця угода дійсно існувала раніше, ніж було 1000 блоків пам'яті», він повинен представити докази, але немає прямих доказів, що безпосередньо підтверджують «ця угода була включена в попередні 1000 блоків пам'яті», тому йому потрібно довести крок за кроком блок за блоком досягнення 1000 попередніх блоків пам'яті, а потім довести наявність цієї угоди в цьому блоку пам'яті.
!
△ Кожен блок вказує на батьківський блок, тому ви можете довести будь-який блок в історії до кінця.
Припустимо, що в даний час це блок пам'яті з номером 10000, і шахрайський челендж хоче надати доказ того, що блок пам'яті з номером 9000 має транзакцію X, претенденту потрібно почати з хешу блоку пам'яті 10000, спочатку довести хеш батьківського блоку пам'яті 9999, підключеного до блоку пам'яті 10000, а потім довести блок пам'яті 9998... До блоку пам'яті 9000 вміст блоку пам'яті 9000 пропонується містити транзакцію X.
Після EIP-2935 буде існувати системний контракт (розміщений за адресою 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), який буде зберігати до 8192 хеш-значень попередніх блоків пам'яті. Кожного разу, коли з'являється новий блок пам'яті, цей системний контракт автоматично оновлюється, записуючи хеш-значення попереднього блоку пам'яті в системний контракт (перезапише 8192 попередніх хеш-значень блоків пам'яті).
У такому випадку у виклику шахрайського Rollup виклик виклику вже не потрібно повільно доводити крок за кроком, що значення певного сховища (відповідно до пам'ятного блоку 9000) системного договору в стані ланцюга на даний момент є хешем пам'ятного блоку 9000. Якщо діапазон перевищує 8192, наприклад, пам'ятний блок 1000, то це просто ще один крок: спочатку довести, що хешове значення пам'ятного блоку 1808 (= 10000 - 8192), а потім довести, що в стані ланцюга на даний момент в системному договорі є хеш-значення пам'ятного блоку 1000.
Це також покладе підвалини для майбутнього безстанційного клієнта (Stateless Client): майбутні легкі вузли більше не повинні зберігати всі заголовки блоків з історії в пам'яті, а лише потребуючи значення хеша або вмісту певного блоку з історії, можуть просити інших надавати докази, використовуючи спосіб доведення, наведений у прикладі шахрайства вище.
EIP-7623: : збільшити вартість даних дзвінків
Збільште вартість публікації даних за допомогою calldata, щоб звільнити достатньо безпечного місця для збільшення ліміту блокового газу та ліміту BLOB.
Зі зростанням попиту на публікацію даних Rollup в EIP-4844 введено Blob, щоб забезпечити надійне зберігання даних за дуже низьку ціну. Збільшення кількості Blob завжди було очікуваною спільнотою оновленням, таким як недавне збільшення ліміту газу блоку, відображає попит екосистеми на збільшення ресурсів.
!
△ Все більше валідаторів висловлюють підтримку збільшенню ліміту блокового газу.
Однак збільшення ліміту блокового газу або кількості блобів чинитиме більший тиск на p2p-мережу Ethereum, оскільки обсяг даних, що передаються, стає більшим, що зробить зловмисників більш ефективними, якщо вартість публікації даних не зросте.
Після випуску протоколу EIP-7623 вартість calldata збільшиться у 2,5 рази, з "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" до "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".
Спочатку, якщо зловмисник використовував весь ліміт газу блоку (30M) для розміщення сміттєвих даних, розмір блоку пам'яті становив би близько 1,79 МБ (30 МБ / 16), порівняно із середнім розміром блоку пам'яті лише близько 100 КБ. Якщо ліміт блокового газу збільшити до 40 М, зловмисник може згенерувати блок пам'яті розміром близько 2,38 МБ. Коли вартість calldata збільшується в 2,5 рази, ефективність зловмисника знижується до максимуму 0,72 МБ для 30 Мб і 0,95 МБ для 40 Мб, щоб ліміт блокового газу та Blob можна було збільшити більш впевнено. Однак цей технічний протокол не хоче впливати на звичайного користувача, який «не використовує calldata для публікації даних», тому він обчислюватиме загальне споживання газу транзакцією двома способами, залежно від того, який з них вищий:
Спочатку обчислювальний спосіб обсягу газу для угод, співставлений зі старою вартістю calldata: це означає, що обсяг calldata обчислюється за допомогою «Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas», і додається обсяг газу, спожитий виконанням угоди, та обсяг газу, спожитий розгортанням контракту.
Просто розрахуйте кількість газу calldata, але використовуйте нову вартість для розрахунку: тобто calldata обчислюється таким чином, як «Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas», але не включає газ, спожитий виконанням, або газ, спожитий при розгортанні контракту, тому для користувачів, які, як правило, «не використовують calldata для публікації даних» (наприклад, переходять на Uniswap для обміну), це основний Gas Споживання - це частина виконання, і навіть якщо calldata розраховується за новою вартістю, вона не перевищить газ, спожитий виконанням, тому звичайних користувачів це не торкнеться.
Реальний вплив буде на менші зведення, оскільки blob-об'єкти мають фіксований розмір і фіксовану комісію, тому малі зведення неефективні для використання blob-об'єктів, і економічно вигідніше використовувати calldata, але після EIP-7623 вартість цих невеликих зведень зросте в 2,5 рази, і їм, можливо, доведеться перейти на використання blob або знайти спосіб об'єднати зусилля, щоб поділитися blob.
EIP-7691: збільшення пропускної здатності BLOB
Збільште кількість blob-об'єктів і додайте більше місця для публікації даних у зведеннях. *
У стандарті EIP-7691 збільшено кількість блобів із «Ціль: 3 Blobs, Max: 6 Blobs» до «Target: 6 Blobs, Max: 9 Blobs», щоб збільшити простір для публікації більшої кількості даних у зведеннях.
Примітка: Крім того, на ринку комісій Blob є деякі проекти, які потрібно доопрацювати, наприклад, швидкість коригування комісії недостатньо миттєва, а мінімальна комісія занадто низька, але це не в проблемі, яку має на меті вирішити цей технічний протокол.
Інші технічні угоди
EIP-7549: Індекс комітету вилучено з валідації
Налаштуйте зміст голосування валідаторів, щоб полегшити агрегацію голосів і зменшити тиск на мережу P2P.
Валідатори випадковим чином розподіляються по групі комітетів і пар для кожної епохи
При блочному голосуванні в пам'яті голоси валідаторів в кожному комітеті можуть бути агреговані разом, що зменшує кількість голосів, пройдених в мережі P2P, але голоси валідатора будуть містити інформацію про кількість комітетів, до яких належить валідатор, а це означає, що голоси різних комітетів не можуть бути агреговані, навіть якщо всі вони голосують в одному блоці пам'яті.
EIP-7549 видаляє інформацію про "якому комітету належить цей перевіряючий" з вмісту голосування, що дозволяє агрегувати перевіряючих з різних комітетів у випадку, коли вміст голосування однаковий, що подальше знижує кількість голосів, що передаються в p2p мережі, зменшуючи тиск на p2p мережу.
EIP-7840: Додайте план BLOB-об'єктів до профілю EL
Створіть файл налаштувань для параметра Blob на рівні виконання, щоб уникнути звертання вузлів рівня виконання до вузлів рівня погодження для отримання відповідних параметрів Blob.
Параметри, пов'язані з BLOB, наразі зберігаються у вузлах рівня консенсусу, але вузли виконавчого рівня все ще потребують цих параметрів у деяких випадках (наприклад, RPC eth_feeHistory), тому вони повинні запитувати вузли рівня консенсусу.
EIP-7840 створює конфігураційний файл для параметрів, пов'язаних із BLOB, на рівні виконання, і вузли на рівні виконання можуть безпосередньо зчитувати параметри, пов'язані з blob, через цей файл конфігурації без необхідності запитувати вузли рівня консенсусу.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ethereum Pectra Хардфорк вступ
Автор: NIC Lin, Medium
Прогнозується, що хардфорк Pectra стартує в мережевому розгортанні у березні 2025 року. Оновлення Pectra містить 11 технічних пакетів (EIP), які включають:
Технічні протоколи стосовно застави
EIP-6110: Попередня компіляція операцій на кривій BLS12-381
Спростіть процес обробки для участі користувачів у стейкінгу, щоб час очікування значно скоротився.
Спосіб участі користувачів у стейкінгу полягає в тому, щоб внести 32 ETH на рівень виконання та записати це журналом подій, а потім рівень консенсусу виконує аналіз журналу подій, щоб визначити, чи бере хтось участь у стейкінгу, а потім користувач, який бере участь у стейкінгу, стає валідатором.
Проте перш за все, валідатори на рівні консенсусу повинні спочатку визначити часову точку для досягнення консенсусу, інакше вони виявлять, що деякі валідатори бачать 5 нових внесків, тоді як інші бачать тільки 3, тому валідатори рівня консенсусу будуть голосувати за блок виконання (eth1data), на який слід посилатися, щоб забезпечити, що всі бачать однаковий блок виконання.
Проте під час початкового проектування для уникнення серйозних помилок на рівні виконання, які можуть призвести до роздвоєння ланцюжків, використовується блок виконання (eth1data), який був створений близько 10 годин тому, щоб забезпечити розробникам консенсусу достатньо часу на реагування та вирішення проблем у випадку серйозних помилок. Однак це також означає, що найшвидший час для активації ставок на участь - це близько 10 годин.
!
△ 10900000 eth1data в блоці CL, записаний в ньому Block Hash - це 21683339 блоку виконавчого шару, який з'явився 10 годин тому.
Після виконання технічного протоколу EIP-6110 дані зобов'язання користувача за контрактом безпосередньо стануть частиною рівня виконання, і оскільки сам блок рівня консенсусу міститиме блок виконавчого рівня (але не eth1data), валідаторам рівня консенсусу більше не потрібно розглядати проблему «підтвердження того, що блок пам'яті еталонного рівня виконання однаковий», доки за блок пам'яті консенсусного рівня проголосують понад дві третини валідаторів, усі досягнуть консенсусу щодо одного блоку рівня виконання. Таким чином, після участі в заставі користувач може дочекатися, поки блок пам'яті виконавчого рівня завершить обробку не раніше ніж за 13 хвилин, а клієнт рівня консенсусу також може видалити складну логіку, яка спочатку використовувалася для обробки даних стейкінгу.
EIP-7002: Зберігання значень хеш-блоків історії в State
Дозволяє вдосконалити процес виходу валідатора з застави або вилучення застави та доходу, знизити ризики валідатора.
Для участі в заставі потрібно мати два ключі: ключ валідатора та ключ виведення.
Ключ валідатора використовується для робочого вмісту валідатора, а облікові дані для виведення коштів використовуються для адреси, на яку буде виведено депозит і заробіток, коли валідатор вийде зі стейкінгу.
Якщо ви втратите ключ валідатора, ви не зможете виконувати функції валідатора та вилучити заставу; якщо ви втратите підтвердження виведення, ви втратите всі ставки та прибутки. Крім того, деякі користувачі використовують сторонні послуги застави, такі як Lido; коли вони використовують ці платформи, користувачам потрібно самостійно зберігати підтвердження виведення, тоді як ключ валідатора зберігається та виконує функції валідатора за допомогою постачальника послуг.
За допомогою технічного протоколу EIP-7002 користувач може викликати «Зняття контракту» (тобто розгорнутого на 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) за допомогою Відкликання облікових даних, щоб вийти з застави (Вихід) або зняти заставу та прибуток (Часткове зняття), що дозволить знизити можливі ризики, пов'язані з використанням послуг сторонньої застави. Якщо користувач самостійно бере участь у заставі, але втратив Ключ валідатора, він також може вийти з застави за допомогою цього.
Примітка: якщо ваша Withdrawal Credential все ще у форматі BLS публічного ключа, не забудьте спочатку переключитися і перетворити його у формат EL-адреси.
EIP-7251: додайте MAX_EFFECTIVE_BALANCE
Збільшення максимального обсягу застави значно скорочує кількість валідаторів, і ті валідатори, які не досягли максимального рівня, можуть автоматично отримувати дохід від застави.
Користувачі, які забезпечують ставку, повинні надати MAX_EFFECTIVE_BALANCE ETH у кількості, яка не може бути ні менше, ні більше (наразі MAX_EFFECTIVE_BALANCE складає 32 ETH). Якщо користувач має 1024 ETH для ставки, він може прийняти участь у 32 ставках, активувати 32 валідатори, виконувати 32 вузли валідатора. Активна участь у ставці призвела до того, що наразі вже близько 1 мільйона валідаторів та постійне збільшення, що призвело до того, що дані стану на рівні згоди стали більшими, що вимагає більшого навантаження на рівні p2p мережі консенсусу, оскільки кожен слот (кожні 12 секунд) вимагає безперервного передавання та агрегування підписів великої кількості валідаторів на рівні p2p мережі.
Після впровадження технічного протоколу EIP-7251 мінімальний ліміт стейкінгу (MIN_ACTIVATION_BALANCE) все ще становить 32 ETH, але верхня межа (MAX_EFFECTIVE_BALANCE) буде значно збільшена до 2048 ETH, ви можете здійснювати стейкінг будь-якої суми ETH між 32~2048, ви можете отримувати винагороду за стейкінг, більше не потрібно регулярно виводити дохід і продовжувати робити ставки на нові ETH після накопичення 32 ETH.
Наразі існуючим валідаторам не потрібно спеціально вийти зі ставки перед поєднанням знову долучитися до ставки, а можна безпосередньо використовувати новий «контракт для об'єднання депозитів на виконавчому рівні» (розгорнутий на 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), щоб валідатор за допомогою його виведення грошових коштів звернувся до контракту з проханням про початок процедури об'єднання депозитів.
Примітка: Якщо ваші облікові дані для виведення коштів мають формат відкритого ключа BLS, вам потрібно спочатку переключити їх на формат адреси EL.
EIP-7685: Загальний запит рівня виконання
CL, щоб користувачі та служби стейкингу могли безпосередньо надсилати запити на рівень консенсусу.
Користувачі можуть надсилати запити безпосередньо з рівня виконання на рівень консенсусу, а сервіси стейкінгу (наприклад, Lido) можуть працювати більш децентралізовано. Наприклад, запит EIP-7002 на зняття стейкінгу та запит EIP-7251 на об'єднання депозитів. Без цього технічного протоколу користувачам Lido довелося б довіряти постачальнику послуг вузлів Lido виконання депозиту без стейкінгу або злиття на рівні консенсусу. За допомогою цього технічного протоколу користувачі Lido можуть надсилати запити безпосередньо через контракт управління на рівні виконання.
Ці запити будуть відрізнятися типом запиту, щоб розрізняти різні типи запитів, а також для того, щоб відправляти запити через різні контракти, нарешті, ці запити будуть записані в блок пам'яті виконавчого рівня, тому шар консенсусу може безпосередньо отримувати цю інформацію через блок пам'яті виконавчого рівня, не потрібно більше писати окрему логіку розбору.
EIP-6110, EIP-7002 та EIP-7251 - всі вони розроблені на основі стандарту, визначеного в EIP-7685, для формування запитів:
(0x00000000219ab540356cbb839cbe05303d7705fa) Ініціювання запиту.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) зробив запит.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Ініціювання запиту.
Технічні протоколи для покращення користувацького досвіду
EIP-7702: Встановлення коду облікового запису EOA
Дозволяє обліковий запис EOA будь-яким чином перевтілюватися в обліковий запис контракту, що значно підвищує зручність використання.
Обліковий запис EOA має деякі недоліки використання, включаючи:
Якщо це розумний контракт (наприклад, Safe), то всі вищезазначені проблеми можуть бути вирішені:
Пропозиція EIP-7702 надає обліковим записам EOA можливість ставати контрактними рахунками. Користувач підписує перетворене повідомлення закритим ключем EOA, який включає «Chain ID», «Змінену адресу контракту» та «EOA Nonce Value»:
Проте є кілька моментів, на які варто звернути увагу:
Навіть якщо обліковий запис EOA користувача стає контрактом, він може продовжувати використовувати його так само, як і початковий обліковий запис EOA. Наприклад, якщо ваш обліковий запис EOA стає безпечним контрактом, ви можете використовувати безпечний інтерфейс, пройти процес безпечної транзакції або продовжувати підписувати та надсилати транзакції за допомогою оригінального гаманця EOA. Однак це також означає, що безпека облікового запису, як і раніше, обмежена приватним ключем.
Навіть якщо обліковий запис користувача EOA перетвориться на багато підписів, поки він не втратить приватний ключ EOA, безпека його облікового запису завжди буде залежати від безпеки приватного ключа EOA: він все ще повинен добре зберігати свій приватний ключ або фразу для відновлення, тому його обліковий запис не стане таким же безпечним, як багато підписів.
Коли обліковий запис EOA перетворюється на контракт та записує дані у свій сховище, ці дані, записані в сховище, не форматуються через зміну облікового запису EOA на інший контракт або скасування перетворення, якщо явно не виконується дія видалення даних, тому розробникам слід уникати читання даних, залишених попереднім контрактом, у сховищі, можна звернутися до ERC-7201.
Зазвичай для контрактів необхідний ініціалізаційний крок, під час розгортання контракту синхронно записати інформацію власника контракту (наприклад, публічний ключ або адресу), щоб уникнути втрати права власності над контрактом через вибірковий запуск (Frontrun). Зазвичай це виконується фабричним контрактом, що розгортає контракт, але через те, що EIP-7702 змінюється безпосередньо, а не через одну фабрику, щоб розгорнути контракт на EOA, злочинець може скопіювати підпис користувача та передати транзакцію на ланцюжок, щоб замінити користувача, але ініціалізувати контракт так, щоб його можна було контролювати злочинцю, тому розробникам потрібно бути обережними з EIP-7702. Можливі заходи захисту, такі як перевірка підпису облікового запису EOA в середині ініціалізаційної функції, навіть якщо вас випередять, злочинець не зможе згенерувати підпис цього облікового запису EOA для завершення ініціалізації.
Гаманець повинен добре перевірити користувача, зупинити запит і попередити користувача, коли шкідливий веб-сайт DApp попросить користувача підписати транзакцію трансформації, інакше, якщо користувач підпише шкідливу транзакцію трансформації, активи будуть миттєво переміщені. Ось кілька прикладів того, як трансформуватися в договір:
Технічний протокол DApp
EIP-2537: Попередня компіляція операцій з кривою BLS12-381
Зменште вартість і зробіть його більш придатним для додатків доказу з нульовим розголошенням на основі кривої BLS.
EIP-2537 додає кілька нових контрактів попередньої компіляції для забезпечення недорогих операцій з кривими BLS, що робить більш можливим розробку додатків для доведення з нульовим розголошенням на основі кривих BLS.
EIP-2935: Збереження хешів історичних блоків у стані
Він дозволяє розробникам або вузлам зчитувати хеш блоків минулих блоків пам'яті безпосередньо зі сховища системного контракту.
Якщо розробнику потрібно довести вміст попереднього блоку пам'яті, наприклад, якщо шахрайський челендж Optimismtic Rollup хоче довести, що транзакція існує в 1000 попередніх блоках пам'яті, претендент не може сказати про це прямо.
«Будь ласка, вірте мені, що ця угода дійсно існувала раніше, ніж було 1000 блоків пам'яті», він повинен представити докази, але немає прямих доказів, що безпосередньо підтверджують «ця угода була включена в попередні 1000 блоків пам'яті», тому йому потрібно довести крок за кроком блок за блоком досягнення 1000 попередніх блоків пам'яті, а потім довести наявність цієї угоди в цьому блоку пам'яті.
!
△ Кожен блок вказує на батьківський блок, тому ви можете довести будь-який блок в історії до кінця.
Припустимо, що в даний час це блок пам'яті з номером 10000, і шахрайський челендж хоче надати доказ того, що блок пам'яті з номером 9000 має транзакцію X, претенденту потрібно почати з хешу блоку пам'яті 10000, спочатку довести хеш батьківського блоку пам'яті 9999, підключеного до блоку пам'яті 10000, а потім довести блок пам'яті 9998... До блоку пам'яті 9000 вміст блоку пам'яті 9000 пропонується містити транзакцію X.
Після EIP-2935 буде існувати системний контракт (розміщений за адресою 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), який буде зберігати до 8192 хеш-значень попередніх блоків пам'яті. Кожного разу, коли з'являється новий блок пам'яті, цей системний контракт автоматично оновлюється, записуючи хеш-значення попереднього блоку пам'яті в системний контракт (перезапише 8192 попередніх хеш-значень блоків пам'яті).
У такому випадку у виклику шахрайського Rollup виклик виклику вже не потрібно повільно доводити крок за кроком, що значення певного сховища (відповідно до пам'ятного блоку 9000) системного договору в стані ланцюга на даний момент є хешем пам'ятного блоку 9000. Якщо діапазон перевищує 8192, наприклад, пам'ятний блок 1000, то це просто ще один крок: спочатку довести, що хешове значення пам'ятного блоку 1808 (= 10000 - 8192), а потім довести, що в стані ланцюга на даний момент в системному договорі є хеш-значення пам'ятного блоку 1000.
Це також покладе підвалини для майбутнього безстанційного клієнта (Stateless Client): майбутні легкі вузли більше не повинні зберігати всі заголовки блоків з історії в пам'яті, а лише потребуючи значення хеша або вмісту певного блоку з історії, можуть просити інших надавати докази, використовуючи спосіб доведення, наведений у прикладі шахрайства вище.
EIP-7623: : збільшити вартість даних дзвінків
Збільште вартість публікації даних за допомогою calldata, щоб звільнити достатньо безпечного місця для збільшення ліміту блокового газу та ліміту BLOB.
Зі зростанням попиту на публікацію даних Rollup в EIP-4844 введено Blob, щоб забезпечити надійне зберігання даних за дуже низьку ціну. Збільшення кількості Blob завжди було очікуваною спільнотою оновленням, таким як недавне збільшення ліміту газу блоку, відображає попит екосистеми на збільшення ресурсів.
!
△ Все більше валідаторів висловлюють підтримку збільшенню ліміту блокового газу.
Однак збільшення ліміту блокового газу або кількості блобів чинитиме більший тиск на p2p-мережу Ethereum, оскільки обсяг даних, що передаються, стає більшим, що зробить зловмисників більш ефективними, якщо вартість публікації даних не зросте.
Після випуску протоколу EIP-7623 вартість calldata збільшиться у 2,5 рази, з "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" до "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".
Спочатку, якщо зловмисник використовував весь ліміт газу блоку (30M) для розміщення сміттєвих даних, розмір блоку пам'яті становив би близько 1,79 МБ (30 МБ / 16), порівняно із середнім розміром блоку пам'яті лише близько 100 КБ. Якщо ліміт блокового газу збільшити до 40 М, зловмисник може згенерувати блок пам'яті розміром близько 2,38 МБ. Коли вартість calldata збільшується в 2,5 рази, ефективність зловмисника знижується до максимуму 0,72 МБ для 30 Мб і 0,95 МБ для 40 Мб, щоб ліміт блокового газу та Blob можна було збільшити більш впевнено. Однак цей технічний протокол не хоче впливати на звичайного користувача, який «не використовує calldata для публікації даних», тому він обчислюватиме загальне споживання газу транзакцією двома способами, залежно від того, який з них вищий:
Реальний вплив буде на менші зведення, оскільки blob-об'єкти мають фіксований розмір і фіксовану комісію, тому малі зведення неефективні для використання blob-об'єктів, і економічно вигідніше використовувати calldata, але після EIP-7623 вартість цих невеликих зведень зросте в 2,5 рази, і їм, можливо, доведеться перейти на використання blob або знайти спосіб об'єднати зусилля, щоб поділитися blob.
EIP-7691: збільшення пропускної здатності BLOB
У стандарті EIP-7691 збільшено кількість блобів із «Ціль: 3 Blobs, Max: 6 Blobs» до «Target: 6 Blobs, Max: 9 Blobs», щоб збільшити простір для публікації більшої кількості даних у зведеннях.
Примітка: Крім того, на ринку комісій Blob є деякі проекти, які потрібно доопрацювати, наприклад, швидкість коригування комісії недостатньо миттєва, а мінімальна комісія занадто низька, але це не в проблемі, яку має на меті вирішити цей технічний протокол.
Інші технічні угоди
EIP-7549: Індекс комітету вилучено з валідації
Налаштуйте зміст голосування валідаторів, щоб полегшити агрегацію голосів і зменшити тиск на мережу P2P.
Валідатори випадковим чином розподіляються по групі комітетів і пар для кожної епохи
При блочному голосуванні в пам'яті голоси валідаторів в кожному комітеті можуть бути агреговані разом, що зменшує кількість голосів, пройдених в мережі P2P, але голоси валідатора будуть містити інформацію про кількість комітетів, до яких належить валідатор, а це означає, що голоси різних комітетів не можуть бути агреговані, навіть якщо всі вони голосують в одному блоці пам'яті.
EIP-7549 видаляє інформацію про "якому комітету належить цей перевіряючий" з вмісту голосування, що дозволяє агрегувати перевіряючих з різних комітетів у випадку, коли вміст голосування однаковий, що подальше знижує кількість голосів, що передаються в p2p мережі, зменшуючи тиск на p2p мережу.
EIP-7840: Додайте план BLOB-об'єктів до профілю EL
Створіть файл налаштувань для параметра Blob на рівні виконання, щоб уникнути звертання вузлів рівня виконання до вузлів рівня погодження для отримання відповідних параметрів Blob.
Параметри, пов'язані з BLOB, наразі зберігаються у вузлах рівня консенсусу, але вузли виконавчого рівня все ще потребують цих параметрів у деяких випадках (наприклад, RPC eth_feeHistory), тому вони повинні запитувати вузли рівня консенсусу.
EIP-7840 створює конфігураційний файл для параметрів, пов'язаних із BLOB, на рівні виконання, і вузли на рівні виконання можуть безпосередньо зчитувати параметри, пов'язані з blob, через цей файл конфігурації без необхідності запитувати вузли рівня консенсусу.