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

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

Нове уявлення полягає в тому, щоб поєднати EVM-MAX з SIMD (одна команда, багато даних) (, SIMD як концепція Ethereum існує вже давно, вперше була запропонована Грегом Колвіном в EIP-616. SIMD може використовуватися для прискорення багатьох форм криптографії, включаючи хеш-функції, 32-бітні STARKs та криптографію на основі решіток. Поєднання EVM-MAX та SIMD робить ці два продуктивні розширення природними партнерами.

Загальний дизайн комбінації EIP буде починатися з EIP-6690, а потім:

• Дозволяє )i( будь-яке непарне або )ii( будь-яку ступінь двійки, що не перевищує 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(, що буде достатньо потужним для реалізації elliptic curve cryptography, малих полів криптографії), таких як 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-код, який може виконувати ті ж завдання, що, можливо, не суттєво вплине на ефективність.

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

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

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

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

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

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

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

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

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

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

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

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