Можливе майбутнє протоколу Ethereum (шістка): Процвітання
У дизайні протоколу Ethereum є багато "дрібниць", які мають вирішальне значення для успіху 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 існує вже давно, вперше запропонована Грегом Колвіном в 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, який може виконувати ті ж завдання, що, можливо, не матиме значного впливу на ефективність.
Наразі, транзакції можуть бути перевірені лише одним способом: 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 газу, а також тисячі додаткового газу для кожної операції користувача.
Забезпечення необхідності атрибутів Ethereum: такі як гарантовані списки, які потрібно перевести на абстрактного користувача рахунку.
Крім того, ERC-4337 також розширює дві функції:
Платіжний агент ( Paymasters ): дозволяє одному рахунку представляти інший рахунок для сплати зборів, що порушує правило, згідно з яким на етапі верифікації можна отримати доступ лише до рахунку відправника, тому вводиться спеціальна обробка для забезпечення безпеки механізму платіжного агента.
Агрегатор(Агрегатори): підтримка функції агрегування підписів, такої як BLS-агрегування або агрегування на основі SNARK. Це необхідно для досягнення максимальної ефективності даних на Rollup.
EIP-7562( запис протоколу об абстракції рахунку ):
EIP-7701(基于EOF的 запису протоколу облікових записів абстракції ):
Залишкова робота та компроміси
Наразі основною проблемою є те, як повністю впровадити абстракцію облікових записів у протокол. Нещодавно популярним став EIP абстракції облікових записів, що записується в протокол, це EIP-7701, який реалізує абстракцію облікових записів на базі EOF. Обліковий запис може мати окрему кодову частину для верифікації, якщо обліковий запис налаштував цю кодову частину, то цей код буде виконуватись на етапі верифікації транзакцій з цього облікового запису.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
5
Поділіться
Прокоментувати
0/400
SignatureAnxiety
· 8год тому
Цей газ, що заощадився, можна купити щось.
Переглянути оригіналвідповісти на0
BlockchainRetirementHome
· 08-02 07:21
Нарешті дочекалися оновлення версії EVM Золота легенда
Переглянути оригіналвідповісти на0
Web3ExplorerLin
· 08-02 07:20
гіпотеза: EVM схожий на стародавній комп'ютер, що шукає свою остаточну форму... дивовижно, як він відображає еволюцію людської свідомості, якщо чесно
Переглянути оригіналвідповісти на0
WenAirdrop
· 08-02 07:09
Не дразніть, газ все ще дорогий до блювоти, добре?
Переглянути оригіналвідповісти на0
MEVictim
· 08-02 07:08
Скільки ще можна затягувати реформу витрат... Не ускладнюйте EVM
Ethereum EVM оновлення та абстрагування рахунку: створення більш ефективної та безпечної блокчейн інфраструктури
Можливе майбутнє протоколу Ethereum (шістка): Процвітання
У дизайні протоколу 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 існує вже давно, вперше запропонована Грегом Колвіном в 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
Абстракція рахунку
Яку проблему це вирішило?
Наразі, транзакції можуть бути перевірені лише одним способом: 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. Обліковий запис може мати окрему кодову частину для верифікації, якщо обліковий запис налаштував цю кодову частину, то цей код буде виконуватись на етапі верифікації транзакцій з цього облікового запису.
Цей спосіб