Майбутнє протоколу Ethereum (шосте): Епізод процвітання

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

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Процвітання: ключова мета

• Перетворити EVM на високопродуктивний та стабільний «кінцевий стан»
• Введення абстракції рахунків у протокол, щоб усі користувачі могли насолоджуватися більш безпечними та зручними рахунками
• Оптимізувати економіку торгових витрат, підвищити масштабованість та одночасно знизити ризики
• Дослідження передової криптографії, яка дозволить Ethereum значно покращитися в довгостроковій перспективі

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Покращення EVM

Яку проблему це вирішило?

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

Що це таке, як це працює?

Першим кроком у поточній дорожній карті вдосконалення EVM є формát об'єкта EVM (EOF), який планується включити в наступний жорсткий форк. EOF є серією EIP, що визначає нову версію коду EVM з багатьма унікальними особливостями, найбільш помітною з яких є:

• Розділення між кодом (може виконуватись, але не може бути прочитано з EVM) та даними (можна читати, але не можна виконувати)
• Заборонено динамічні переходи, дозволено лише статичні переходи
• Код EVM більше не може спостерігати за інформацією, пов'язаною з паливом
• Додано новий механізм явного підпрограми

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

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

Досить новою ідеєю є поєднання EVM-MAX з характеристиками одноінструкційної багатоданності (SIMD), яка як концепція Ethereum існує вже досить довго, вперше була запропонована Greg Colvin у EIP-616. SIMD може бути використаний для прискорення багатьох форм криптографії, включаючи хеш-функції, 32-бітні STARKs та криптографію на основі решіток. Поєднання EVM-MAX і SIMD робить ці два варіанти розширення, орієнтовані на продуктивність, природним поєднанням.

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Існуючі дослідження посилання

• У порівн.
• EVM-MAX:
• У порівн.

Залишкова робота та балансування

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

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

Необхідно виконати важливу роботу, яка полягає у реалізації функцій, подібних до EVM-MAX з SIMD, а також проведенні бенчмаркінгу споживання газу для різних криптографічних операцій.

Як взаємодіяти з іншими частинами дорожньої карти?

L1 налаштовує свій EVM так, щоб L2 також могло легше проводити відповідні налаштування. Якщо обидва не проводитимуть синхронізовані налаштування, це може призвести до несумісності та негативних наслідків. Крім того, EVM-MAX та SIMD можуть знизити витрати gas для багатьох систем доказів, що робить L2 більш ефективним. Це також полегшує заміну більшої кількості попередньо скомпільованих кодів на EVM код, що виконує ті ж завдання, що, ймовірно, не матиме значного впливу на ефективність.

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Абстракція рахунку

Яку проблему це вирішило?

Наразі перевірка транзакцій може здійснюватися лише одним способом: підписом ECDSA. Спочатку абстракція облікового запису мала на меті вийти за межі цього, дозволяючи логіці перевірки облікового запису бути будь-яким кодом EVM. Це може активувати цілий ряд застосувань:

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

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

Що це таке і як це працює?

Ядро абстракції облікового запису просте: дозволити смарт-контрактам ініціювати транзакції, а не лише EOA. Уся складність виникає з реалізації цього в спосіб, який є дружнім до підтримки децентралізованої мережі та запобігає атакам відмови в обслуговуванні.

Після багаторічних зусиль, спрямованих на розширення функціональності при обмеженні ризику відмови в обслуговуванні (DoS), врешті-решт було знайдено рішення для реалізації «ідеальної абстракції облікового запису»: ERC-4337.

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

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Існуючі посилання на дослідження

• Презентація про історію абстракції рахунків:
• ERC-4337:
• ЄІП-7702:
• Код BLSWallet (використовуючи функцію агрегування):
• EIP-7562 (запис протоколу абстракції рахунків):
• EIP-7701 (протокол абстракції рахунків на основі EOF):

Залишкова робота та компроміси

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

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

Як це взаємодіє з іншими частинами дорожньої карти?

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

! Віталік про можливе майбутнє Ethereum (6): The Splurge

EIP-1559 покращення

Яку проблему це вирішує?

EIP-1559 було активовано в 2021 році на Ethereum, що значно покращило середній час включення блоків.

Однак реалізація EIP-1559 на даний момент не є ідеальною в кількох аспектах:

1. Формула має деякі недоліки: вона не націлена на 50% блоків, а приблизно на 50-53% заповнені блоки, в залежності від варіації.
2. У крайніх випадках корекція недостатньо швидка.

Формула для blobs (EIP-4844) була спеціально розроблена для вирішення першої проблеми і є загалом більш зрозумілою. Проте EIP-1559 сам по собі, так і EIP-4844 не намагалися вирішити другу проблему.

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

Що таке багатовимірний Gas, як він працює?

Рішення цих низькоефективних проблем – це багатовимірний газ: встановлення різних цін і обмежень для різних ресурсів. Ця концепція технічно незалежна від EIP-1559, але наявність EIP-1559 робить реалізацію цього рішення більш легкою. Якби не EIP-1559, оптимально упакувати блок, що містить різні обмеження ресурсів, було б складною багатовимірною задачею рюкзака. А з EIP-1559 більшість блоків не досягнуть повного навантаження за будь-якими ресурсами, тому проста алгоритмічна схема «приймати будь-яку угоду за достатню плату» є достатньою.

На даний момент у нас вже є багатовимірний Gas для виконання та даних блоків; в принципі, ми можемо розширити його на більше вимірів: такі як calldata (дані транзакцій), читання / запис стану та розширення розміру стану.

EIP-7706 введено новий вимір gas, спеціально для calldata. Водночас, воно спростило багатовимірний механізм gas, об'єднавши три типи gas в один (в стилі EIP-4844) фрейм, що також вирішує математичні недоліки EIP-1559. EIP-7623 є більш точним рішенням, яке більш суворо обмежує максимальний calldata для середнього та найгіршого випадків ресурсних проблем, не вводячи цілком новий вимір.

! Віталік про можливе майбутнє Ethereum (6): The Splurge

Існуючі дослідження посилань

• EIP-1559 FAQ: EIP-1559 FAQ
• Про емпіричний аналіз EIP-1559: Empirical analysis
• Дозволяє швидке коригування пропозицій щодо вдосконалень: Proposed improvements
• Частина про механізм базових витрат у EIP-4844 FAQ: EIP-4844 FAQ
• EIP-7706: EIP