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

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

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

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

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

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

EVM покращення

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

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

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

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

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

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

Після впровадження 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 (включаючи циклічні та нециклічні), принаймні для ступенів 2. Одночасно додати ISZERO (який виведе результат на основний стек EVM), що буде достатньо потужним для реалізації криптографії на еліптичних кривих, малих полів (як Poseidon, Circle STARKs), традиційних хеш-функцій (як SHA256, KECCAK, BLAKE) та криптографії на основі решіток. Інші оновлення EVM також можуть бути реалізовані, але до цього часу їх увага була нижчою.

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

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

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

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):

залишок