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

У дизайні протоколу 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 робить ці два орієнтовані на продуктивність розширення природним поєднанням.

Попередній дизайн комбінації EIP буде починатися з EIP-6690, а потім:

• Дозволяє (i) будь-яке непарне число або (ii) будь-яку степінь 2, що не перевищує 2768, як модуль
• Для кожної EVM-MAX команди( додавання, віднімання, множення) додайте версію, яка більше не використовує 3 безпосередніх числа x, y, z, а використовує 7 безпосередніх чисел: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. У Python коді ці команди виконують подібні функції:

для i в діапазоні ( count ): mem[z_start + z_skip * кількість] = op( mem[x_start + x_skip * кількість], mem[y_start + y_skip * кількість] )

У реальному виконанні це буде оброблятися паралельно.

• Можливо додати XOR, AND, OR, NOT та SHIFT(, включаючи цикли та нецикли), принаймні для степенів двійки. Одночасно додати ISZERO(, що виведе дані на основний стек EVM), що буде достатньо потужним для реалізації криптографії на еліптичних кривих, криптографії на малих полях(, таких як Poseidon, Circle STARKs), традиційних хеш-функцій(, таких як SHA256, KECCAK, BLAKE) та криптографії на основі решіток. Інші оновлення EVM також можуть бути реалізовані, але поки що мають нижчий рівень уваги.

! Віталік про можливе майбутнє 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 полягає в поділі обробки операцій користувача на два етапи: перевірка та виконання. Всі перевірки спочатку обробляються, а всі виконання обробляються потім. У мемпулі операції користувача приймаються лише тоді, коли етап перевірки стосується лише його власного рахунку і не читає змінні середовища. Це дозволяє запобігти атакам з множинними відмовами. Крім того, до етапу перевірки також застосовуються суворі обмеження gas.

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

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

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

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

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

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

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

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

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

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

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