Можливі напрямки розвитку протоколу Ethereum у майбутньому: Багатство

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

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

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

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

Покращення EVM

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

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

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

Першим кроком у поточній дорожній карті вдосконалення EVM є формат об'єкта EVM (EOF), який планується включити в наступному жорсткому форк. EOF є серією EIP, яка визначає нову версію коду EVM з багатьма унікальними характеристиками, найзначніша з яких:

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

Структура коду EOF включає сегменти коду, даних та інформації про тип.

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

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

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

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

• ЕОФ:
• ЕВМ-МАКС:
• СІМД:

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

Наразі 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 для сплати газу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EIP-1559 покращення

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

EIP-1559 було активовано в 2021 році на Ethereum, що значно покращило середній час включення блоку. Проте, поточна реалізація EIP-1559 не є ідеальною в багатьох аспектах:

1. Формула має незначний недолік: вона не націлена на 50% блоків, а на приблизно 50-53% заповнених блоків, що залежить від варіації (, що пов'язано з тим, що математики називають "нерівністю арифметично-геометричного середнього" ).
2. У крайніх випадках корекція відбувається недостатньо швидко.

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

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

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

Що таке багатовимірний Gas, як він працює?

Рішення цих неефективних проблем є багатовимірний Gas: встановлення різних цін та обмежень для різних ресурсів. Ця концепція технічно незалежна від EIP-1559, але EIP-1