Майбутнє протоколу 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 — спочатку за рахунок трохи зменшеного байткоду завдяки функціям підпрограм, а потім завдяки новим функціям або зменшеним витратам на газ, специфічним для EOF.

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

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

Новою ідеєю є поєднання EVM-MAX з особливістю одноінструкційної багатоданності (SIMD), SIMD як концепція Ethereum існує вже давно, вперше була запропонована Greg Colvin у 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 в 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-код, який може виконувати ті ж завдання, що, можливо, не вплине на ефективність.

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

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

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

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

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

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

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

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

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: наприклад, включений список, створений для гарантій, які потрібно перевести на обліковий запис абстрактного користувача.

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

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

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

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

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

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

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