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

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

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

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

• Перетворити 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-бітні STARK та криптографію на основі решіток. Поєднання EVM-MAX та SIMD робить ці два орієнтованих на продуктивність розширення природним поєднанням.

! [Віталік про можливе майбутнє Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(

Загальний дизайн комбінації 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 в range)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 також можуть бути реалізовані, але поки що мають менше уваги.

)# Залишкова робота та ваги

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

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

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

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

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

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

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

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

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

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

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

MPC) багатосторонні обчислення( — це технологія, яка існує вже 40 років, що використовується для розподілу ключа на кілька частин і зберігання їх на різних пристроях, використовуючи криптографічні технології для генерації підписів без необхідності безпосереднього об’єднання цих частин ключа.

! [Віталік про можливе майбутнє Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

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

Ця робота почалася з EIP-3074 і врешті-решт сформувалася в EIP-7702. EIP-7702 надає "зручні функції" абстракції рахунків усім користувачам, включаючи сьогоднішні EOA) зовнішні рахунки, які контролюються підписами ECDSA (.

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

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

Ядро абстракції рахунків просте: дозволити смарт-контрактам ініціювати транзакції, а не тільки 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 (: дозволяє одному рахунку представляти інший рахунок для сплати зборів, що порушує правило, що на етапі перевірки можна отримати доступ лише до рахунку відправника, тому було введено спеціальну обробку для забезпечення безпеки механізму платіжного агента.
• Агрегатори): підтримка функцій агрегації підписів, таких як агрегація BLS або агрегація на основі SNARK. Це необхідно для досягнення максимальної ефективності даних на Rollup.

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

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

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

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

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

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

Основне співвідношення, здається, полягає в "швидкому написанні рішення, яке задовольняє меншу кількість людей" та "очікуванні довшого часу