Можливості майбутнього протоколу Ethereum: процвітання
У дизайні протоколу Ethereum є багато "деталей", які є критично важливими для його успіху. Приблизно половина змісту стосується різних типів покращень EVM, решта складається з різних нішевих тем, ось у чому полягає сенс "процвітання".
Процвітання: ключова мета
Перетворити 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 робить ці два орієнтовані на продуктивність розширення природною парою.
Наразі планується включити EOF у наступний хардфорк. Хоча завжди є можливість видалити його в останній момент — у попередніх хардфорках були функції, які були тимчасово видалені, але це буде великою проблемою. Видалення EOF означає, що будь-яке майбутнє оновлення EVM потрібно буде проводити без EOF, хоча це можливо, але може бути складніше.
Головний компроміс EVM полягає у складності L1 та складності інфраструктури, EOF - це велика кількість коду, який потрібно додати до реалізації EVM, статичний аналіз коду також відносно складний. Проте, в обмін на це, ми можемо спростити високорівневі мови, спростити реалізацію EVM та отримати інші переваги. Можна стверджувати, що пріоритетна карта шляхів постійного вдосконалення Ethereum L1 має включати й будуватися на EOF.
Необхідно виконати важливу роботу, яка полягає в реалізації функцій, подібних до EVM-MAX з SIMD, а також в бенчмаркінгу споживання газу для різних криптографічних операцій.
Як взаємодіяти з іншими частинами дорожньої карти?
L1 налаштовує свій EVM, щоб L2 також міг легше здійснювати відповідні налаштування. Якщо обидва не синхронізують свої налаштування, це може призвести до несумісності та негативних наслідків. Крім того, EVM-MAX та SIMD можуть знизити витрати gas для багатьох систем доказів, що робить L2 більш ефективним. Це також спрощує заміну більшої кількості попередньо скомпільованих кодів на EVM-код, який може виконувати ті ж завдання, що, можливо, не вплине значно на ефективність.
Наразі транзакції можуть бути підтверджені лише одним способом: підписом 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 полягає в розділенні обробки користувацьких операцій на два етапи: верифікацію та виконання. Спочатку обробляється вся верифікація, а потім виконується вся обробка. У мемпулі приймаються лише ті користувацькі операції, етап верифікації яких стосується лише їх власного рахунку і не читає змінні середовища. Це допомагає запобігти атакам з множинним скиданням. Крім того, до етапу верифікації також застосовуються суворі обмеження на газ.
ERC-4337 був розроблений як додатковий стандарт протоколу (ERC), оскільки на той час розробники клієнтів Ethereum зосередилися на злитті (Merge) і не мали додаткових сил для обробки інших функцій. Саме тому ERC-4337 використовує об'єкти, що називаються користувацькими операціями, замість звичайних транзакцій. Однак нещодавно ми усвідомили необхідність записати принаймні частину з них у протокол.
Дві ключові причини такі:
EntryPoint як вроджена неефективність контракту: кожен пакет має фіксовані витрати близько 100,000 gas, а також тисячі gas додатково для кожної операції користувача.
Забезпечення необхідності атрибутів Ethereum: наприклад, список, що містить гарантії, які потрібно перевести на обліковий запис абстрактного користувача.
Крім того, ERC-4337 також розширює дві функції:
Платіжний агент ( Paymasters ): дозволяє одному рахунку платити збори від імені іншого рахунку, що порушує правило, згідно з яким на етапі перевірки можна отримати доступ лише до рахунку відправника, тому було введено спеціальну обробку для забезпечення безпеки механізму платіжного агента.
Агрегатор ( Aggregators ): підтримує функцію агрегації підписів, таку як агрегація BLS або агрегація на основі SNARK. Це необхідно для досягнення максимальної ефективності даних на Rollup.
Презентація про історію абстракції облікового запису:
ERC-4337:
ЄІП-7702:
Код BLSWallet ( використовує функцію агрегації ):
EIP-7562( запис протоколу об абстракції рахунку ):
EIP-7701( базований на EOF протокол запису облікових записів абстракції ):
Залишкова робота та компроміси
Наразі основною проблемою є те, як повністю впровадити абстракцію рахунку в протокол. Нещодавно популярний запис протоколу абстракції рахунку EIP — це EIP-7701, який реалізує абстракцію рахунку на основі EOF. Один рахунок може мати окрему частину коду для верифікації; якщо рахунок налаштує цю частину коду, то цей код буде виконуватись під час етапу верифікації транзакцій з цього рахунку.
Ця методика має своєрідну привабливість, оскільки чітко вказує на дві еквівалентні перспективи абстракції локального облікового запису:
Включити EIP-4337 як частину протоколу
Новий тип EOA, де алгоритм підпису - виконання коду EVM
Якщо ми почнемо з суворого обмеження складності виконуваного коду під час перевірки --- не дозволяючи доступ до зовнішнього стану, навіть початкові обмеження gas будуть занадто низькими, щоб бути ефективними для квантової стійкості або захисту приватності --- тоді безпека цього підходу є дуже очевидною: просто замінити ECDSA перевірку на виконання коду EVM, що потребує схожого часу.
Однак, з часом нам потрібно розширити ці межі, оскільки дозволити застосування захисту конфіденційності працювати без реле, а також квантова стійкість є вельми важливими. Для цього нам потрібно знайти більш гнучкі способи вирішення ризиків відмови в обслуговуванні (DoS), не вимагаючи, щоб етапи верифікації були надзвичайно спрощеними.
Основні компроміси, здається, полягають у "швидкому написанні рішення, яке задовольняє меншу кількість людей" та "очікуванні довший час, можливо, отримуючи більш ідеальне рішення"; ідеальний підхід, можливо, є певним змішаним методом. Один з змішаних методів полягає в тому, щоб швидше написати кілька випадків використання та виділити більше часу для дослідження інших випадків використання. Інший підхід полягає в тому, щоб спочатку реалізувати більш амбітну версію абстракції облікових записів на L2. Проте виклик, з яким стикаються, полягає в тому, що команда L2 повинна бути впевнена в роботі, що приймає пропозицію, щоб бути готовою до впровадження, особливо для забезпечення того, щоб L1 та/або інші L2 в майбутньому могли приймати сумісні рішення.
Ще одне застосування, яке ми повинні чітко розглянути, - це рахунки для зберігання ключів, які зберігають пов'язаний з рахунком стан на L1 або спеціалізованому L2, але можуть функціонувати на L1 і будь-де.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Ethereum процвітання дорожня карта: оновлення EVM, абстрагування рахунку та оптимізація EIP-1559
Можливості майбутнього протоколу Ethereum: процвітання
У дизайні протоколу Ethereum є багато "деталей", які є критично важливими для його успіху. Приблизно половина змісту стосується різних типів покращень EVM, решта складається з різних нішевих тем, ось у чому полягає сенс "процвітання".
Процвітання: ключова мета
Покращення EVM
Яку проблему це вирішило?
Нинішня EVM важка для статичного аналізу, що ускладнює створення ефективних реалізацій, формальну верифікацію коду та подальше розширення. Крім того, ефективність EVM є низькою, що ускладнює реалізацію багатьох форм високорівневої криптографії, якщо не забезпечити явну підтримку через попередньо скомпільовані програми.
Що це таке, як це працює?
Першим кроком у поточній дорожній карті покращення EVM є формат об'єкта EVM (EOF), який планується включити у наступний жорсткий форк. EOF є серією EIP, що визначає нову версію коду 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 робить ці два орієнтовані на продуктивність розширення природною парою.
! Віталік про можливе майбутнє Ethereum (6): The Splurge
Існуючі посилання на дослідження
Залишена робота та компроміси
Наразі планується включити EOF у наступний хардфорк. Хоча завжди є можливість видалити його в останній момент — у попередніх хардфорках були функції, які були тимчасово видалені, але це буде великою проблемою. Видалення EOF означає, що будь-яке майбутнє оновлення EVM потрібно буде проводити без EOF, хоча це можливо, але може бути складніше.
Головний компроміс EVM полягає у складності L1 та складності інфраструктури, EOF - це велика кількість коду, який потрібно додати до реалізації EVM, статичний аналіз коду також відносно складний. Проте, в обмін на це, ми можемо спростити високорівневі мови, спростити реалізацію EVM та отримати інші переваги. Можна стверджувати, що пріоритетна карта шляхів постійного вдосконалення Ethereum L1 має включати й будуватися на EOF.
Необхідно виконати важливу роботу, яка полягає в реалізації функцій, подібних до EVM-MAX з SIMD, а також в бенчмаркінгу споживання газу для різних криптографічних операцій.
Як взаємодіяти з іншими частинами дорожньої карти?
L1 налаштовує свій EVM, щоб L2 також міг легше здійснювати відповідні налаштування. Якщо обидва не синхронізують свої налаштування, це може призвести до несумісності та негативних наслідків. Крім того, EVM-MAX та SIMD можуть знизити витрати gas для багатьох систем доказів, що робить 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, але основну мету безпеки, яка була спочатку висунута в пропозиції про абстракцію рахунків, можна досягти лише шляхом повернення і вирішення первісної проблеми: дозволити коду смарт-контракту контролювати верифікацію транзакцій. Причина, чому це досі не реалізовано, полягає в безпечному впровадженні, що є викликом.
! Віталік про можливе майбутнє Ethereum (6): The Splurge
Що це таке, як це працює?
Ядро абстракції рахунку просте: дозволити смарт-контрактам ініціювати транзакції, а не лише EOA. Уся складність походить від реалізації цього способом, який є дружнім до підтримки децентралізованої мережі та запобігає атакам відмови в обслуговуванні.
Типовим ключовим викликом є проблема множинних відмов:
Якщо 1000 функцій перевірки облікових записів залежать від якогось єдиного значення S, і поточне значення S робить всі транзакції в пам'яті дійсними, то єдина транзакція, яка змінює значення S, може зробити всі інші транзакції в пам'яті недійсними. Це дозволяє зловмиснику надсилати сміттєві транзакції в пам'ять з дуже низькою вартістю, що призводить до блокування ресурсів вузлів мережі.
Після багатьох років зусиль, що мали на меті розширення функціональності при обмеженні ризиків відмови в обслуговуванні (DoS), врешті-решт було знайдено рішення для реалізації "ідеальної абстракції рахунків": ERC-4337.
Принцип роботи ERC-4337 полягає в розділенні обробки користувацьких операцій на два етапи: верифікацію та виконання. Спочатку обробляється вся верифікація, а потім виконується вся обробка. У мемпулі приймаються лише ті користувацькі операції, етап верифікації яких стосується лише їх власного рахунку і не читає змінні середовища. Це допомагає запобігти атакам з множинним скиданням. Крім того, до етапу верифікації також застосовуються суворі обмеження на газ.
ERC-4337 був розроблений як додатковий стандарт протоколу (ERC), оскільки на той час розробники клієнтів Ethereum зосередилися на злитті (Merge) і не мали додаткових сил для обробки інших функцій. Саме тому ERC-4337 використовує об'єкти, що називаються користувацькими операціями, замість звичайних транзакцій. Однак нещодавно ми усвідомили необхідність записати принаймні частину з них у протокол.
Дві ключові причини такі:
Крім того, ERC-4337 також розширює дві функції:
! Віталік про можливе майбутнє Ethereum (6): The Splurge
Існуючі посилання на дослідження
Залишкова робота та компроміси
Наразі основною проблемою є те, як повністю впровадити абстракцію рахунку в протокол. Нещодавно популярний запис протоколу абстракції рахунку EIP — це EIP-7701, який реалізує абстракцію рахунку на основі EOF. Один рахунок може мати окрему частину коду для верифікації; якщо рахунок налаштує цю частину коду, то цей код буде виконуватись під час етапу верифікації транзакцій з цього рахунку.
Ця методика має своєрідну привабливість, оскільки чітко вказує на дві еквівалентні перспективи абстракції локального облікового запису:
Якщо ми почнемо з суворого обмеження складності виконуваного коду під час перевірки --- не дозволяючи доступ до зовнішнього стану, навіть початкові обмеження gas будуть занадто низькими, щоб бути ефективними для квантової стійкості або захисту приватності --- тоді безпека цього підходу є дуже очевидною: просто замінити ECDSA перевірку на виконання коду EVM, що потребує схожого часу.
Однак, з часом нам потрібно розширити ці межі, оскільки дозволити застосування захисту конфіденційності працювати без реле, а також квантова стійкість є вельми важливими. Для цього нам потрібно знайти більш гнучкі способи вирішення ризиків відмови в обслуговуванні (DoS), не вимагаючи, щоб етапи верифікації були надзвичайно спрощеними.
Основні компроміси, здається, полягають у "швидкому написанні рішення, яке задовольняє меншу кількість людей" та "очікуванні довший час, можливо, отримуючи більш ідеальне рішення"; ідеальний підхід, можливо, є певним змішаним методом. Один з змішаних методів полягає в тому, щоб швидше написати кілька випадків використання та виділити більше часу для дослідження інших випадків використання. Інший підхід полягає в тому, щоб спочатку реалізувати більш амбітну версію абстракції облікових записів на L2. Проте виклик, з яким стикаються, полягає в тому, що команда L2 повинна бути впевнена в роботі, що приймає пропозицію, щоб бути готовою до впровадження, особливо для забезпечення того, щоб L1 та/або інші L2 в майбутньому могли приймати сумісні рішення.
Ще одне застосування, яке ми повинні чітко розглянути, - це рахунки для зберігання ключів, які зберігають пов'язаний з рахунком стан на L1 або спеціалізованому L2, але можуть функціонувати на L1 і будь-де.