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

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

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

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

Загальний дизайн комбінації 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(, що буде достатньо потужним для реалізації криптографії на еліптичних кривих, малопольової криптографії), такої як 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-8930b556d169a2bc7168ddc2e611d3df.webp(

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![Віталік про можливе майбутнє Ethereum（