Можливе майбутнє протоколу 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, існує вже давно, вперше була запропонована Greg Colvin в EIP-616. SIMD може використовуватися для прискорення багатьох форм криптографії, включаючи хеш-функції, 32-бітні STARKs і криптографію на основі решіток. Поєднання 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), включаючи циклічні та нециклічні (, принаймні для степенів 2. Одночасно додати 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-річною історією, що використовується для розподілу ключа на кілька частин і зберігання їх на кількох пристроях, використовуючи криптографічні технології для генерації підписів без необхідності безпосередньо об'єднувати ці частини ключа.

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

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

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

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

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

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

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

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

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

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

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

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

Головний