Перспективи Ethereum: оновлення EVM та абстрагування рахунку ведуть до процвітання протоколу

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

Автор: Віталік Бутерін

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

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

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

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

Покращення EVM

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

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

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

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

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

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

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

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

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

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

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

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

  • У порівн.
  • EVM-MAX:
  • У порівн.

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

Наразі 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

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

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

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

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

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

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

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

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

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

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 9
  • Поділіться
Прокоментувати
0/400
SelfRuggervip
· 10год тому
Віталік Бутерін, ти правий!
Переглянути оригіналвідповісти на0
GreenCandleCollectorvip
· 07-15 02:02
Віталік Бутерін вийшов на сцену, це означає, що буде щось хороше!
Переглянути оригіналвідповісти на0
GateUser-9ad11037vip
· 07-14 15:00
Віталік Бутерін знову випустив нову роботу~ деталі вирішують успіх, безумовно.
Переглянути оригіналвідповісти на0
NightAirdroppervip
· 07-14 04:50
EVM ще має продовжувати боротьбу.
Переглянути оригіналвідповісти на0
StealthDeployervip
· 07-14 04:47
V що робить? Знову возиться з кодом
Переглянути оригіналвідповісти на0
WhaleWatchervip
· 07-14 04:45
Після оновлення Вахути подолати ці технологічні бар'єри буде важко.
Переглянути оригіналвідповісти на0
MidnightGenesisvip
· 07-14 04:44
Кодова частота аномальна, знову є плани на нічну розгортку.
Переглянути оригіналвідповісти на0
TokenSherpavip
· 07-14 04:25
насправді, *зітхання* ця пропозиція не має належного історичного контексту... дозвольте мені пояснити, чому evm 1.0 був недосконалим з першого дня
Переглянути оригіналвідповісти на0
OnChainArchaeologistvip
· 07-14 04:24
увійти в позицію тільки на обличчя В-сина
Переглянути оригіналвідповісти на0
Дізнатися більше
  • Закріпити