Технічний директор Paradigm: Інтерпретація празького хардфорку після оновлення Ethereum Cancun

Слова: Георгіос Константопулос, технічний директор, Paradigm

Упорядник: Луффі, Foresight News

Мета цієї статті — надати огляд поглядів команди Paradigm Reth на те, які EIP слід включити до Празького хардфорку (наступне велике оновлення Consensus Ethereum після хардфорку Cancun) та нашого загального плану щодо «EL Core Dev» у 2024 році. Наступні погляди постійно розвиваються і представляють поточні погляди команди Reth і не обов’язково представляють всю команду Paradigm.

Ми вважаємо, що празький хардфорк, швидше за все, матеріалізується на EthereumTestnet у 3 кварталі 2024 року та в основній мережі до кінця року. Вона повинна включати в себе:

• EIP, пов’язані зі стейкінгом, такі як EIP-7002, який підтримує повторний стейкінг і пули стейкінгу без довіри.
• Окремі варіації EVM.
• Ми готові співпрацювати з будь-якою командою, яка хоче глибше зазирнути в Прагу або інший майбутній хард-форк EL, і раді надати рекомендації та допомогу щодо модифікації кодової бази Reth.

Що робити:

• Ми вважаємо, що наступні EIP повинні бути пріоритетними: 7002, 6110, 2537.
• Ми підтримуємо EOF, описану в специфікації, і сподіваємося якнайшвидше завершити сферу застосування та створити мета-EIP.
• Ми готові додати EIP-4844 Max Blob Gas. У нас немає думки щодо конкретних цифр, але ми запрошуємо людей, які працюють з даними, попрацювати з нами над цією темою.
• Ми раді випустити версію EIP-7547: вона містить список, який допоможе базовому шару протистояти цензурі.

Чого не можна робити:

• Ми не підтримуємо включення Verkle Tries до празького хардфорку, але підтримуємо команду клієнтів, щоб розпочати роботу над цим у 2 кварталі 2024 року із зобов’язанням випустити оновлення в Осаці у 2025 році.
• Ми не вважаємо, що нам слід збільшувати ліміт на виконання L1 або розмір контракту, але ми запрошуємо фахівців з обробки даних працювати з нами, щоб дослідити його вплив на мережу. Ми готові змінити наше сприйняття, тому що минулі випробування показали, що Reth Node без проблем справляється зі збільшеним навантаженням.
• Ми вважаємо, що EIP Wallet/Account Abstraction потрібно тестувати більш змагально, щоб краще зрозуміти простір компромісу. Якщо вони не є взаємовиключними, то в майбутньому ми будемо готові розгорнути кілька EIP, пов’язаних з АА.
• Якщо спільнота погодиться з чутками про бекдор АНБ, ми можемо перетнути межу щодо EIP-7212 (secp256r1).
• Інші теми дорожньої карти: У нас немає фактичного розуміння з’єднання вилок CL EIP або CL/EL, але EIP 7549 і 7251 виглядають багатообіцяючими. Ми також хочемо зробити свій внесок у роботу PeerDAS з боку EL, наскільки це можливо. На даний момент ми хочемо уникнути введення коренів SSZ (EIPs 6404, 6465, 6466). Нарешті, ми бачимо можливість надати довгострокове рішення для архівування даних для прострочених блобів, історії та стану, оскільки і EIP-4844, і EIP-4444 чітко вказують на це, і ще належить визначити, чи готовий Ethereum надати таке рішення.

Детально розглянемо його нижче.

Чим зайнятися

В анотації ми підтримуємо: 1) подальше подолання розриву між CL і EL, і 2) модифікації EVM можуть виконуватися як сольна робота, і можуть тестуватися окремо і паралельно.

EIP-7002

Цей EIP розблоковує пули повторного стейкінгу та стейкінгу без довіри, дозволяючи смарт-контрактам на стороні EL контролювати 1 або більше валідаторів на стороні CL. На наш погляд, це принаймні дозволить існуючим пулам стейкінгу прибрати рівень централізації зі смарт-контракту, який дозволяє виводити кошти.

Впровадження попередньої компіляції зі збереженням стану в EVM — це нова абстракція, яку нам потрібно отримати в нашій реалізації EVM, але крім цього, ми вважаємо, що це простий EIP.

EIP-6110

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

EIP-2537

В даний час існує кілька реалізацій BLS12-381, яка є часто використовуваною кривою в багатьох SNARK, BLS Signature Algorithms і EIP-4844. Ми вважаємо, що він має низьку складність реалізації, оскільки він розкриває алгоритм валідації кривої лише через попередньо скомпільований інтерфейс. Нам також може знадобитися хеш кривої BLS12-381, попередньо скомпільований.

EOF

*Примітка перекладача: EOF розшифровується як EVM Object Format, що перекладається як об’єктний формат Ethereum, і містить серію EIP, які обіцяють зробити виконання Ethereum більш ефективним, послідовним і таким, що оновлюється. Ранні плани були реалізовані в Shanghai Upgrade, який пізніше був скасований. *

EOF підтримуватиме як Solidity, так і Vyper. Немає сумнівів, що форматування коду та налаштування верифікації значно спростять аналіз байт-коду, і ми рекомендуємо ретельно розглянути все інше. Нижче ми порекомендували кілька EIP, але готові вдосконалити їх далі.

З позитивних моментів:

• Зміни, що стосуються лише EVM, які можна протестувати за допомогою Ethereum / Testnet і впровадити однією особою.
• Зміни в EVM, які хочуть Vyper і Solidity
• Допомагає підвищити продуктивність і збільшити ліміти розміру контракту.
• Усуває необхідність аналізу байт-коду під час виконання EVM. Без кешування час на аналіз може досягати 50% і збільшуватися зі збільшенням розміру контракту.
• Увімкніть часткове завантаження коду, щоб допомогти виконувати великі смарт-контракти.
• Devex: Дозволить виправити проблему “занадто глибокого стека” за допомогою dupN/swapN та інших покращень інструментів.
• Перспективність: Нові функції можуть бути безпечно впроваджені в L2, і інструмент знатиме, що сумісно.

Погані аспекти:

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

Ми вважаємо, що наступні функції EOF мають бути розгорнуті у 2024 році. Ми рекомендуємо визначити масштаби та взяти на себе зобов’язання щодо впровадження якомога швидше. Все інше слід враховувати для подальших розгортань. Наші рекомендації:

• EIP-3540 (EOF - EVM Object Format v1): представляє коди та контейнери даних, а також додає структуру та керування версіями до байт-коду Ethereum.
• EIP-3670 (EOF - Code Validation): Відхиляє будь-який контракт, який не відповідає формату EOF під час розгортання. Виконайте більш структурований код і вимкніть недійсні та невизначені директиви.
• EIP-663 (Infinite SWAP & DUP Instructions): Це вирішує проблему «занадто глибокого стека» в монолітності та має побічні ефекти як миттєве значення за допомогою аналізу JUMPDEST. Дуже бажана особливість мови EVM.
• EIP-4200 (EOF - Static Relative Jumps): Кращий статичний аналіз без невизначених стрибків. Краща компіляція AOT. Стрибки більше сприяють повторному використанню коду.
• EIP-4750 (EOF - функція): Вимагає роздільної здатності підпрограм, які можуть використовувати динамічні стрибки, але не статичні стрибки. Він також дозволяє частково завантажувати код, що ідеально працює з Verkle для збільшення ліміту розміру контракту.
• EIP-5450 (EOF - Stack Validation): перевірка вимог до коду та стека. Вилучено перевірки переповнення та переповнення стека виконання для всіх інструкцій, крім CALLF (EIP-4750)
• EIP-7480 (EOF - Data Section Access Instruction): Дозволяє доступ до частини даних байт-коду.
• EIP-7069 (Покращена директива CALL): Можливість прибрати спостережуваність газу з CALL, що полегшить перецінку на газ у майбутньому. Незважаючи на те, що ми не маємо відношення до EOF, ми розглядаємо це як хорошу можливість для його запровадження.

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

Ми оцінюємо вищезазначене навантаження в 1 людину, яка працює повний робочий день протягом 1-2 місяців. Ми готові ще більше звузити його.

Примітка щодо застарілого байт-коду:

• Хоча ми можемо заборонити новий застарілий/неEOF байт-код, ми не можемо скасувати існуючий застарілий байт-код, який фактично діє як EOF “v0”. Застарілий байт-код все ще вимагає аналізу JUMPDEST після EOF і все ще вимагає спеціальної обробки коду для фрагментації його на фрагменти в Verkle Trys.
• Наскільки нам відомо, неможливо перевірити перетворення з байт-коду, відмінного від EOF, в EOF, без доступу до вихідного коду, але ми готові розглянути механізми для полегшення цього перетворення.
• Крім того, ми були б готові вивчити способи примусової міграції штатів до EOF.

Збільште кількість ляпок EIP-4844

Ми відкриті до цієї зміни, яка відповідатиме збільшенню MAX_BLOB_GAS_PER_BLOCK та TARGET_BLOB_GAS_PER_BLOCK. EIP-4844 говорить:

Виберіть значення TARGET_BLOB_GAS_PER_BLOCK та MAX_BLOB_GAS_PER_BLOCK так, щоб вони відповідали цільовому показнику 3 BLOBs (0,375 МБ) на блок (до 6 blob). Ці невеликі початкові обмеження призначені для мінімізації навантаження на мережу, спричиненого EIP, і очікується, що кількість ляпок збільшиться в майбутніх оновленнях, оскільки мережа демонструє надійність на більших блоках.

Насправді, це невелика зміна коду, і нам потрібно дослідити її фактичний вплив на пул транзакцій, але ми подумали, що можемо повторно використовувати інфраструктуру стрес-тестування EIP-4844 для цього. Можливо, CL буде важко розповсюджувати більше плям, і ми поважаємо думку команди CL.

Не робіть

Веркл намагається

Tl; TL;DR: Ми не бачимо спроб розгорнути Verkle наприкінці 2024/на початку 2025 року. Ми рекомендуємо команді виділити ресурси для цього у 2 кварталі 2024 року та взяти на себе зобов’язання розгорнути хардфорк в Осаці у 2-3 кварталах 2025 року.

З позитивних моментів:

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

Недоліки:

• Вплив змін та зусиль щодо впровадження та тестування.
• Зміни в розрахунку газу: Verkle Tries вводить розмір свідка у функцію розрахунку газу. Ми стурбовані тим, що зміни в ціноутворенні на сховища ще не досліджені (наприклад, яка вартість найбільших споживачів газу після Verkle)?
• Інтеграція додатків: Що повинен робити додаток з валідатором Merkle Patricia Trie, коли виконується перехід Overlay? Як поводитися eth_getProof?

Хоча ми розуміємо переваги Verkle Try, ми вважаємо, що необхідно більше уваги приділяти тому, як сторонні інструменти/контракти повинні вписуватися в нього, і який вплив це матиме на рівень 2 та подібні під час перехідного періоду. Спочатку у нас були сумніви щодо міграційної стратегії, оскільки в ній говорилося, що спроба Веркла повинна бути оновлена, коли штат буде прочитаний з уже існуючого MPT, але це вже не так. Тому ми підтримуємо оверлейний підхід як життєздатний шлях міграції.

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

Тому ми, як і раніше, підтримуємо його розгортання у 2025 році замість розгортання у Празькому хардфорку.

L1 Ліміт газу

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

Ми запрошуємо інших працювати з нами над дослідженнями в цьому напрямку, часто пов’язаними з порушенням обліку ресурсів в EVM. Дисертація «Зламаний лічильник» є гарною відправною точкою для досліджень у цій галузі.

Абстракція облікового запису

Ми хотіли б включити 1 або більше EIP, але ми хотіли б бачити більше порівнянь користувацького досвіду та досвіду розробників між кожною пропозицією, щоб краще зрозуміти компроміси та зусилля, пов’язані з інтеграцією інструментів. Ми розглядаємо наступні EIP/ERC, але, будь ласка, не соромтеся радити нам:

• EIP-3074: код операції AUTH і AUTHCALL
• ERC-4337: Використання Alt Mempool для абстракції облікового запису
• EIP-5806: Делегована транзакція
• EIP-5920: Код операції PAY
• EIP-6913: директива SETCODE
• EIP-7377: Транзакції міграції
• RIP-7560: Нативна абстракція облікового запису - Core EIP - Fellowship of Ethereum Magicians

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