Майбутнє протоколу 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, або зменшені витрати на газ.

Після впровадження 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])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(

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

Наразі 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]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(

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

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

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

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

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

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

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

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

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

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

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

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

Ядро абстракції рахунків просте: дозволити смарт-контрактам ініціювати транзакції, а не лише 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])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(

)# Залишкова робота та ваги

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

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

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

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

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