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

Автор: Віталік Бутерін

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

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

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

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

Поліпшення EVM

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

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

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

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

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

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

Процвітання: поліпшення 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 для оплати газу.

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

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