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

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

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

• Перетворити 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 робить ці два орієнтовані на продуктивність розширення природними партнерами.

На практиці це буде оброблятися паралельно.

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

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

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

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

Як взаємодіяти з іншими частинами дорожньої карти?

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

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

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

Типовим ключовим викликом є проблема множинних відмов:

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

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

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

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

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

Два ключові причини такі:

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

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

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

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

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

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

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

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

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

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

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

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

)# Як це взаємодіє з іншими частинами дорожньої карти?

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