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

У дизайні протоколу 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, існує вже давно, вперше запропонована Грегом Колвіном у EIP-616. SIMD можна використовувати для прискорення багатьох форм криптографії, включаючи хеш-функції, 32-бітні STARKs та криптографію на основі решіток. Поєднання EVM-MAX і SIMD робить ці два орієнтовані на продуктивність розширення природними партнерами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ми також повинні чітко розглянути ще один застосунок - обліковий запис зберігання ключів, це