У дизайні протоколу Ethereum багато "деталей" є вирішальними для його успіху. Насправді, близько половини змісту стосується різних типів вдосконалень EVM, решта складається з різних нішевих тем, що і є суттю "складності".
Процвітання: ключова мета
Перетворити EVM на високопродуктивний та стабільний "кінцевий стан"
Впровадження абстракції облікового запису в протокол, що дозволяє всім користувачам користуватися більш безпечним і зручним обліковим записом
Оптимізація економіки торгових витрат, підвищення масштабованості при одночасному зниженні ризику
Дослідження передової криптографії, що значно покращить Ethereum в довгостроковій перспективі
В даний час 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) будь-яку ступінь двійки, що не перевищує 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-ec1638a809393a6ed42724fb08f534da.webp(
Абстракція рахунку
) Яку проблему це вирішило?
Наразі транзакції можуть бути підтверджені лише одним способом: підписом 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])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Що це таке, як це працює?
Основна суть абстракції облікового запису проста: дозволити смарт-контрактам ініціювати транзакції, а не лише EOA. Уся складність виникає з реалізації цього способу, який є дружнім до підтримки децентралізованої мережі та запобігає атакам відмови в обслуговуванні.
Типовим ключовим викликом є проблема множинних відмов:
Якщо верифікаційна функція 1000 облікових записів залежить від певного єдиного значення S, і поточне значення S робить всі транзакції в мемпулі дійсними, тоді єдина транзакція, яка змінює значення S, може зробити всі інші транзакції в мемпулі недійсними. Це дозволяє зловмиснику з дуже низькими витратами надсилати сміттєві транзакції в мемпул, що призводить до блокування ресурсів мережевих вузлів.
Після багатьох років зусиль, спрямованих на розширення функцій при обмеженні ризику відмови в обслуговуванні ###DoS(, врешті-решт було знайдено рішення для реалізації "ідеальної абстракції рахунку": ERC-4337.
Принцип роботи ERC-4337 полягає в розділенні обробки дій користувача на два етапи: перевірка та виконання. Спочатку обробляється вся перевірка, а потім виконується виконання. У пулі пам'яті приймаються лише ті дії користувача, перевірка яких стосується лише його власного рахунку та не зчитує змінні середовища. Це допомагає запобігти атакам з множинними збоїми. Крім того, для етапу перевірки також запроваджуються суворі обмеження на газ.
ERC-4337 був розроблений як додатковий стандарт протоколу )ERC(, оскільки на той момент розробники клієнтів Ethereum зосередилися на злитті )Merge( і не мали додаткових сил для обробки інших функцій. Ось чому ERC-4337 використовує об'єкти, які називаються користувацькими операціями, замість звичайних транзакцій. Проте, нещодавно ми усвідомили необхідність записати принаймні частину з цього в протокол.
Два ключові причини такі:
EntryPoint як вроджена неефективність контракту: кожен пакет має фіксовані витрати близько 100,000 gas, а також додаткові тисячі gas для кожної операції користувача.
Необхідність забезпечення атрибутів Ethereum: наприклад, перелік створених включень гарантує, що потрібно перевести на обліковий запис абстрактного користувача.
! [Віталік про можливе майбутнє Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Крім того, ERC-4337 також розширює дві функції:
Платіжний агент ) Paymasters (: дозволяє одному рахунку представляти інший рахунок для сплати зборів, що порушує правило, згідно з яким на стадії верифікації можна отримати доступ лише до рахунку самого відправника, тому було введено спеціальну обробку для забезпечення безпеки механізму платіжного агента.
Агрегатор)Агрегатори(: підтримка функцій агрегації підписів, таких як агрегація BLS або агрегація на основі SNARK. Це необхідно для досягнення максимальної ефективності даних на Rollup.
) Існуючі дослідження посилання
Доповідь про історію абстракції рахунків:
ERC-4337:
ЄІП-7702:
Код BLSWallet ### використовує функцію агрегації (:
EIP-7562) запис у протокол абстракції рахунків (:
EIP-7701)протокол запису на основі EOF абстракції рахунків (:
) Залишкова робота та ваги
Наразі основне питання, яке потрібно вирішити, це як повністю впровадити абстракцію облікових записів у протокол, нещодавно популярний запис протоколу абстракції облікових записів EIP є EIP-7701, ця пропозиція реалізує абстракцію облікових записів на базі EOF. Обліковий запис може мати окрему частину коду для верифікації, якщо обліковий запис налаштував цю частину коду, то цей код буде виконуватися на етапі верифікації транзакцій з цього облікового запису.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
5
Репост
Поділіться
Прокоментувати
0/400
GweiTooHigh
· 08-12 00:28
Чи справді абстрагування рахунку може стати популярним?
Переглянути оригіналвідповісти на0
MEVictim
· 08-10 08:39
Це всього лише питання EVM, нудно.
Переглянути оригіналвідповісти на0
BlockchainDecoder
· 08-10 08:39
Цитуючи дані з статті RV2022 року, ефективність стеку існуючої архітектури EVM становить лише 42%, дійсно потребує оптимізації.
Переглянути оригіналвідповісти на0
PessimisticOracle
· 08-10 08:39
Скільки б не говорили, все одно це просто брехня? Якщо це справді збудеться, вважай, що я програв.
Перспективи Ethereum: оновлення EVM та абстрагування рахунку ведуть до нового етапу процвітання
Майбутнє протоколу Ethereum (шосте): процвітання
У дизайні протоколу Ethereum багато "деталей" є вирішальними для його успіху. Насправді, близько половини змісту стосується різних типів вдосконалень EVM, решта складається з різних нішевих тем, що і є суттю "складності".
Процвітання: ключова мета
! Віталік про можливе майбутнє Ethereum (6): The Splurge
Покращення EVM
Яку проблему це вирішило?
В даний час EVM важко піддається статичному аналізу, що ускладнює створення ефективних реалізацій, формальну верифікацію коду та подальше розширення. Крім того, EVM має низьку ефективність, що ускладнює реалізацію багатьох форм високорівневої криптографії, якщо це не здійснюється через явну підтримку попередньо скомпільованих функцій.
Що це таке, як це працює?
Перший крок у поточній дорожній карті вдосконалення EVM - це формат об'єкта EVM (EOF), який планується включити в наступний хард-форк. EOF - це ряд EIP, які визначають нову версію коду EVM з багатьма унікальними характеристиками, найзначнішими з яких є:
! Віталік про можливе майбутнє Ethereum (6): The Splurge
Старі контракти продовжать існувати і можуть бути створені, хоча врешті-решт старі контракти ( можуть поступово бути виведені з експлуатації або навіть примусово конвертовані в код 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
Попередній дизайн комбінації EIP буде починатися з EIP-6690, а потім:
Пітон Для I в range(count): mem[z_start + z_skip * кількість] = op( mem[x_start + x_skip * кількість], mem[y_start + y_skip * кількість] )
У реальному впровадженні це буде оброблено паралельно.
) Існуючі дослідження посилання
Залишилася робота та ваги
Наразі планується включити 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-ec1638a809393a6ed42724fb08f534da.webp(
Абстракція рахунку
) Яку проблему це вирішило?
Наразі транзакції можуть бути підтверджені лише одним способом: підписом 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])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) Що це таке, як це працює?
Основна суть абстракції облікового запису проста: дозволити смарт-контрактам ініціювати транзакції, а не лише EOA. Уся складність виникає з реалізації цього способу, який є дружнім до підтримки децентралізованої мережі та запобігає атакам відмови в обслуговуванні.
Типовим ключовим викликом є проблема множинних відмов:
Якщо верифікаційна функція 1000 облікових записів залежить від певного єдиного значення S, і поточне значення S робить всі транзакції в мемпулі дійсними, тоді єдина транзакція, яка змінює значення S, може зробити всі інші транзакції в мемпулі недійсними. Це дозволяє зловмиснику з дуже низькими витратами надсилати сміттєві транзакції в мемпул, що призводить до блокування ресурсів мережевих вузлів.
Після багатьох років зусиль, спрямованих на розширення функцій при обмеженні ризику відмови в обслуговуванні ###DoS(, врешті-решт було знайдено рішення для реалізації "ідеальної абстракції рахунку": ERC-4337.
Принцип роботи ERC-4337 полягає в розділенні обробки дій користувача на два етапи: перевірка та виконання. Спочатку обробляється вся перевірка, а потім виконується виконання. У пулі пам'яті приймаються лише ті дії користувача, перевірка яких стосується лише його власного рахунку та не зчитує змінні середовища. Це допомагає запобігти атакам з множинними збоїми. Крім того, для етапу перевірки також запроваджуються суворі обмеження на газ.
ERC-4337 був розроблений як додатковий стандарт протоколу )ERC(, оскільки на той момент розробники клієнтів Ethereum зосередилися на злитті )Merge( і не мали додаткових сил для обробки інших функцій. Ось чому ERC-4337 використовує об'єкти, які називаються користувацькими операціями, замість звичайних транзакцій. Проте, нещодавно ми усвідомили необхідність записати принаймні частину з цього в протокол.
Два ключові причини такі:
! [Віталік про можливе майбутнє Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
Крім того, ERC-4337 також розширює дві функції:
) Існуючі дослідження посилання
) Залишкова робота та ваги
Наразі основне питання, яке потрібно вирішити, це як повністю впровадити абстракцію облікових записів у протокол, нещодавно популярний запис протоколу абстракції облікових записів EIP є EIP-7701, ця пропозиція реалізує абстракцію облікових записів на базі EOF. Обліковий запис може мати окрему частину коду для верифікації, якщо обліковий запис налаштував цю частину коду, то цей код буде виконуватися на етапі верифікації транзакцій з цього облікового запису.
Цей метод захоплюючий