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

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

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

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

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

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

Покращення EVM

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

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

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

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

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

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

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

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

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

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

• Дозволяє (i) будь-яке непарне число або (ii) будь-яку ступінь двійки, що не перевищує 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), що буде достатньо потужним для реалізації криптографії elliptic curve, малих полів криптографії(, таких як 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-код, який може виконувати ті ж завдання, що, можливо, не вплине суттєво на ефективність.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цей метод