Майбутні можливі напрямки розвитку протоколу Ethereum: епізод процвітання

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

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

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

Покращення EVM

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

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

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

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

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

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

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

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

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

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

• ЕОФ:
• ЕВМ-МАКС:
• СІМД:

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

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

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

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

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

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

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

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

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

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

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

Дозволити протоколу конфіденційності працювати без ретрансляцій, значно знизивши його складність і усунувши одну ключову центральну точку залежності.

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

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

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

Типовим ключовим викликом є проблема множинних відмов:

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

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

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

ERC-4337 був розроблений як додатковий стандарт протоколу (ERC), оскільки на той час розробники клієнтів Ethereum зосередилися на злитті (Merge) і не мали додаткової енергії для вирішення інших функцій. Саме тому ERC-4337 використовує об'єкт, відомий як користувацька операція, а не звичайні транзакції. Однак нещодавно ми усвідомили необхідність записати принаймні частину з цього в протокол.

Два ключових причини такі:

1. EntryPoint як вроджена неефективність контракту: кожен пакет має фіксовані витрати близько 100,000 gas, а також кілька тисяч gas для кожної операції користувача.
2. Забезпечення необхідності атрибутів Ethereum: як список, що містить гарантії, які потрібно передати абстрактному користувачеві рахунку.

Крім того, ERC-4337 розширює дві функції:

• Платіжний агент ( Paymasters ): дозволяє одному рахунку сплачувати витрати від імені іншого рахунку, що порушує правило, згідно з яким на етапі верифікації можна отримати доступ лише до самого рахунку відправника, тому було введено спеціальну обробку для забезпечення безпеки механізму платіжного агента.
• Агрегатори(Aggregators): підтримка функцій агрегації підписів, таких як BLS-агрегація або агрегація на основі SNARK. Це необхідно для досягнення максимальної ефективності даних у Rollup.

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

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

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

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

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

Ця методика приваблива тим, що чітко демонструє два еквівалентні погляди на абстракцію локального облікового запису:

1. Включити EIP-4337 як частину протоколу
2. Новий тип EOA, де алгоритм підпису виконується кодом EVM

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

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

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

Ще одне застосування, яке нам потрібно чітко розглянути, - це облікові записи для зберігання ключів, які зберігають стан облікового запису на L1 або спеціалізованому L2, але можуть використовуватися на L1 і будь-якому сумісному L2. Ефективна реалізація цього може вимагати підтримки L2 таких опкодів, як L1SLOAD або REMOTESTATICCALL, але це також потребує підтримки цих операцій у реалізації абстракції облікових записів на L2.

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

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

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

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

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

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

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

1. Формула має деякі недоліки: вона не орієнтується на 50% блоків, а на приблизно 50-53% заповнених блоків, що залежить від варіації (, що пов'язано з тим, що математики називають "нерівністю аритметично-геометричного середнього".