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

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

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

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

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

Покращення EVM

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

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

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

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

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

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

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

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

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

! Віталік про можливе майбутнє 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 для сплати газу.

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

Основна суть абстракції облікового запису проста: дозволити смарт-контрактам ініціювати транзакції, а не лише EOA. Вся складність полягає в реалізації цього способом, який є дружнім до підтримки децентралізованої мережі та захищає від атак відмови в обслуговуванні.

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

Після багатьох років зусиль, спрямованих на розширення функціональності при обмеженні ризику відмови в обслуговуванні (DoS), врешті-решт було досягнуто рішення для реалізації "ідеальної абстракції рахунку": ERC-4337.

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

Принцип роботи ERC-4337 полягає в розділенні обробки дій користувача на два етапи: верифікація та виконання. Спочатку обробляється вся верифікація, а потім всі виконання. У мемпулі приймаються лише ті дії користувача, етап верифікації яких стосується тільки його власного рахунку та не читає змінні середовища. Це дозволяє запобігти атакам множинного збою. Крім того, для етапу верифікації також суворо застосовуються обмеження на газ.

ERC-4337 був розроблений як додатковий стандарт протоколу (ERC), оскільки на той час розробники клієнтів Ethereum зосереджувалися на злитті (Merge) і не мали додаткових ресурсів для обробки інших функцій. Ось чому ERC-4337 використовує об'єкт, відомий як операція користувача, а не звичайну угоду. Проте нещодавно ми усвідомили необхідність написати принаймні частину з цього в протокол.

Два ключові причини наведені нижче:

1. EntryPoint як вроджена неефективність контракту: кожен пакет має фіксовані витрати близько 100,000 газу, а також тисячі газу за додаткові операції кожного користувача.
2. Забезпечення необхідності атрибутів Ethereum: наприклад, включені в список створені включення гарантій, які потрібно передати абстрактному користувачу рахунку.

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

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

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

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

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

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

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

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

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

Основні компроміси, здається, полягають у "швидкому написанні рішення, яке задовольняє меншу кількість людей" та "очікуванні довше, можливо, для досягнення більш ідеального рішення", ідеальним варіантом може бути певний змішаний підхід. Один з варіантів змішаного підходу – це швидше написати деякі випадки використання та залишити більше часу для дослідження інших випадків використання. Інший варіант – спочатку впровадити більш амбітну версію абстракції облікових записів на L2. Однак викликом є те, що команди L2 повинні бути впевнені в роботі пропозиції для того, щоб бути готовими до реалізації, особливо для того, щоб забезпечити, що L1 і/або інші L2 в майбутньому зможуть впроваджувати сумісні рішення.

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

Ще один застосунок, який потрібно чітко розглянути, - це облікові записи для зберігання ключів, які зберігають стан, пов'язаний з обліковим записом, на L1 або спеціалізованому L2, але можуть використовуватися на L1 і будь-якому сумісному L2. Ефективна реалізація цього може вимагати, щоб L2 підтримував такі функції, як L1SLOAD або REMOTESTATI