Ethereum має на меті стати світовою книгою обліку: платформою для зберігання цивілізаційних активів і записів, основою для фінансів, управління, сертифікації даних з високою доданою вартістю тощо. Це вимагає виконання двох умов: масштабованості та стійкості. Хардфорк Fusaka має на меті збільшити доступний обсяг даних другого рівня (L2) у 10 разів, а поточна запланована дорожня карта на 2026 рік також пропонує подібне значне розширення першого рівня (L1). Тим часом, Ethereum завершив оновлення до механізму доказу частки (Proof of Stake), різноманітність його клієнтів швидко зростає, триває робота в напрямку перевірки нульових знань (ZK Verifiability) та стійкості до квантових обчислень, а також різні застосунки стають дедалі надійнішими.
Ця стаття має на меті зосередитися на одному з аспектів стійкості (яка в кінцевому підсумку також вплине на масштабованість), який є не менш важливим, але його легко недооцінити, а саме на простоті протоколу.
Однією з великих переваг біткоїна є його надзвичайно простий та елегантний протокол.
Блокчейн складається з серії блоків, кожен з яких з'єднаний з попереднім блоком за допомогою хешу. Валідність блоку перевіряється механізмом proof-of-work, тобто перевіряється, що перші кілька цифр його хеш-значення дорівнюють нулю. Кожен блок містить кількість транзакцій, які споживають монети, які або видобуваються, або отримані в результаті виведення попередніх транзакцій. Саме в цьому полягає основний механізм протоколу Bitcoin. Навіть здібні учні середніх класів можуть повністю розуміти цей протокол, а програмісти навіть можуть писати клієнтам як аматорські проекти.
Збереження простоти протоколу забезпечує ключову перевагу для того, щоб біткойн або ефір стали глобально визнаним нейтральним базовим рівнем:
Простіші протоколи легше аналізувати, що може залучити більше учасників до дослідження, розробки та управління протоколами, а також знизити ризик технологічної монополії.
Спрощена структура протоколу суттєво зменшує витрати на розробку інтеграції з новою інфраструктурою (такою як клієнти, доказники, інструменти журналювання та інші розробницькі інструменти).
Простий дизайн угоди ефективно знижує довгострокові витрати на обслуговування.
Серйозні ризики вразливості в специфікаціях протоколу та їх реалізації значно зменшено, що полегшує перевірку безпеки системи.
Зменшення соціальної атаки: спростження компонентів робить систему легшою для захисту від проникнення спеціальних інтересів, підвищуючи загальну безпеку.
Протягом історії Ethereum часто не вдалося реалізувати принципи простоти в проектуванні протоколу (частково через мої рішення), що безпосередньо призвело до високих витрат на розробку, частих загроз безпеці та закритості культури розробки. Корені цих проблем часто полягають у прагненні до короткострокових вигод, які виявилися недійсними на практиці. У цій статті буде розглянуто, як Ethereum може досягти близькості до простоти протоколу Bitcoin протягом наступних п'яти років.
Спрощений рівень консенсусу
Моделювання фіналізації трьох часових слотів у 3sf - mini (кодова назва тестової мережі Ethereum)
Нова версія рішення для рівня консенсусу (раніше відома як «Світловий ланцюг») має на меті інтеграцію досягнень досліджень за останнє десятиліття в галузях теорії консенсусу, нульових знань (ZK-SNARK), економіки стейкингу та інших, щоб створити оптимальний механізм консенсусу для Ethereum, орієнтуючи його на довгостроковий розвиток. У порівнянні з існуючою Beacon Chain, це рішення має значно спрощені характеристики, що виявляються в наступних аспектах:
Трьохслотова фінальність (3-slot finality) архітектурна інновація: усунула концептуальне розділення незалежних слотів (slot) та епох (epoch), скасувала механізм ротації комітету та складні компоненти синхронного комітету, значно спростивши протокол. Основна реалізація потребує лише близько 200 рядків коду, досягаючи майже оптимального рівня безпеки в порівнянні з протоколом Gasper.
Оптимізація управління валідаційними вузлами: обмежуючи кількість активних валідаційних вузлів, можна реалізувати спрощене рішення для правил вибору розгалуження (fork choice rule), при цьому забезпечуючи безпеку системи.
Оновлення агрегаційного протоколу: механізм агрегації на основі STARK дозволяє будь-якому вузлу виконувати роль агрегації, уникаючи залежності від довіри до агрегатора та проблеми витрат ресурсів через повторювані бітові поля (bitfield). Незважаючи на те, що сама агрегаційна криптографія є досить складною, її висока ступінь інкапсуляції суттєво знижує системні ризики.
Покращення архітектури P2P-мережі: вказані вище два оптимізації створили можливості для побудови більш простої та ефективної архітектури точка-точка.
Реконструкція процесу верифікації: повторний дизайн механізмів допуску, виходу, зняття коштів, міграції ключів та покарання за бездіяльність в той час, коли зменшується обсяг коду, та чітке визначення механізму забезпечення основних параметрів (таких як період слабкої суб'єктивності).
Технічні переваги: відносна декомпозиція між рівнем консенсусу та рівнем виконання EVM забезпечує більший технічний простір для безперервної оптимізації. У порівнянні з цим, аналогічні вдосконалення на рівні виконання стикаються з більшими викликами.
Спрощений рівень виконання
Складність віртуальної машини Ethereum (EVM) продовжує зростати, при цьому багато складних дизайнів виявилися непотрібними (у багатьох випадках це були мої помилки в ухваленні рішень): 256-бітна віртуальна машина, надмірно оптимізована для певного криптографічного алгоритму, який наразі поступово втрачає свою важливість; а також надмірно розроблені попередньо скомпільовані контракти для єдиного сценарію використання, фактична використання яких є вкрай низькою.
Спроби вирішити існуючі проблеми шляхом фрагментарних виправлень стали неможливими. Видалення операційного коду SELFDESTRUCT вимагало величезних зусиль, але принесло лише обмежені результати, а нещодавні суперечки щодо EOF ще більше підкреслили труднощі поступових змін у віртуальній машині.
В якості альтернативи я нещодавно запропонував більш радикальний шлях трансформації: замість того, щоб робити середню (але все ще руйнівну) модифікацію EVM в обмін на 1,5-кратний приріст продуктивності, я б просто перейшов на нову і значно кращу архітектуру віртуальних машин для стрибка продуктивності в стократний раз. Подібно до The Merge, ми збільшуємо стратегічну цінність кожної зміни, зменшуючи кількість непрацюючих змін. Зокрема, рекомендується замінити існуючий EVM на архітектуру RISC-V або віртуальну машину, яка використовується програмою доказу Ethereum ZK. Ця трансформація принесе:
Революційне підвищення ефективності: у середовищі ZK-доказів смарт-контракти можуть безпосередньо працювати на цільовій архітектурі без витрат на інтерпретатор. Стислі дані показують, що у більшості сценаріїв продуктивність може зростати більш ніж у сто разів.
Архітектура максимально спрощена: специфікація RISC-V є значно більш стиснутою в порівнянні з EVM, інші кандидатні рішення (наприклад, Cairo) також мають прості характеристики.
Спадкування основних переваг EOF: включає в себе управління сегментацією коду, більш дружню підтримку статичного аналізу та більші обмеження на обсяг коду.
Розширення інструментів для розробників: Solidity та Vyper можуть додати підтримку нових архітектур через нову компіляцію на стороні сервера; якщо вибрати RISC-V, розробники основних мов можуть безпосередньо переносити існуючий код.
Оптимізація попередньо скомпільованих контрактів: більшість функцій попередньо скомпільованих контрактів більше не буде необхідна, залишаться лише високоефективні обчислення еліптичних кривих (можуть бути усунуті внаслідок розвитку квантових обчислень).
Основним викликом є те, що, на відміну від рішень EOF, які можуть бути реалізовані негайно, новій віртуальній машині потрібен більше часу, щоб принести користь розробникам. Можна реалізувати частину цінних покращень EVM (наприклад, підвищення обмеження розміру коду контракту, оптимізація набору інструкцій DUP/SWAP) як короткострокове перехідне рішення.
Ця трансформація суттєво спростить архітектуру віртуальної машини. Основне питання полягає в тому: як належним чином обробити існуючу екосистему EVM?
Стратегія зворотної сумісності для міграції віртуальних машин
最大ним викликом спростити (або оптимізувати, не збільшуючи складність) будь-яку частину EVM є балансування між досягненням очікуваних цілей і підтримкою зворотної сумісності з існуючими застосунками.
По-перше, необхідно чітко визначити: навіть для одного клієнта немає єдиного стандарту для визначення того, що таке «кодова база Ethereum».
Мета полягає в мінімізації зеленої області: тобто вузол виконує логіку, необхідну для участі в консенсусі Ethereum, включаючи обчислення поточного стану, генерацію та перевірку доказів, FOCIL (примітка: потрібно підтвердити, чи є це абревіатурою професійного терміна) та процес побудови «базового» блоку.
Помаранчева зона не може бути зменшена: якщо функції виконувального шару (незалежно від того, чи це віртуальна машина, попередньо скомпільований контракт або інші механізми) будуть видалені з протокольних специфікацій або їх функціональність зміниться, клієнти, які обробляють історичні блоки, повинні зберегти цю функцію; але нові клієнти (включаючи ZK-EVM або інструменти формальної верифікації) можуть повністю ігнорувати цю частину.
Новий жовтий сектор: це код, який має велике значення для аналізу даних на поточному ланцюзі або оптимального побудови блоків, але не належить до механізму консенсусу. Типовими прикладами є підтримка операцій користувачів ERC-4337 з боку Etherscan та деяких будівельників блоків. Якщо замінити основні функції Ethereum (такі як зовнішні рахунки EOA та різні старі типи транзакцій, які вони підтримують) на реалізацію RISC-V на ланцюзі, код консенсусу суттєво спроститься, але спеціалізовані вузли можуть все ще потребувати використання оригінального коду для обробки аналізу.
Складність оранжевої та жовтої зон належить до складності упаковки, будь-яка особа, що бажає зрозуміти протокол, може пропустити ці частини, а рішення реалізації Ethereum може вільно вибрати ігнорувати їх. Крім того, дефекти коду в цих зонах не викликають ризику консенсусу. Це означає, що, порівняно зі складністю коду в зеленій зоні, складність оранжевої та жовтої зон має значно менший негативний вплив на загальну систему.
Ідея перенесення коду з зеленої зони в жовту зону подібна до технічного рішення Apple, яке реалізує тривалу зворотну сумісність за допомогою шару перекладу Rosetta.
Вимога, щоб усі нові розроблені попередньо скомпільовані контракти обов'язково містили нормативну реалізацію RISC-V на ланцюгу. Цей крок має на меті поступове адаптування екосистеми до середовища віртуальної машини RISC-V (з прикладом переходу від EVM до RISC-V, це рішення також підходить для міграції з EVM до Cairo або інших більш оптимальних віртуальних машин):
Подвійна підтримка віртуальних машин: на рівні протоколу одночасно нативно підтримуються дві віртуальні машини RISC-V та EVM. Розробники можуть вільно обирати мову програмування, контракти, написані для різних віртуальних машин, можуть безперешкодно взаємодіяти.
Покрокова заміна попередньо скомпільованих контрактів: усі попередньо скомпільовані контракти, крім операцій з еліптичними кривими та алгоритму хешування KECCAK (через їхнє екстремальне оптимізування для продуктивності), будуть замінені на реалізацію RISC-V через жорсткий форк.
Конкретні дії полягають у тому, щоб одночасно видалити первісний попередньо скомпільований контракт, а також змінити код за цією адресою (з використанням моделі DAO fork) з порожнього стану на відповідну реалізацію RISC-V. Завдяки високій простоті архітектури RISC-V, навіть якщо виконати лише цей крок, загальна складність системи все ще зменшиться.
Впровадження EVM-інтерпретатора на блокчейні: реалізація EVM-інтерпретатора на базі RISC-V (інструментальний набір ZK-доказів вже сприяв такій розробці) і його розгортання в якості смарт-контракту на блокчейні. Через кілька років після випуску початкової версії, існуючі EVM-контракти будуть виконуватися за допомогою цього інтерпретатора, що забезпечить плавний перехід на нову віртуальну машину.
Спрощення шляхом реалізації компонентів спільного протоколу
Після завершення четвертого етапу безліч «EVM-рішень» залишаться і будуть використовуватись для оптимізації побудови блоків, інструментів для розробників та аналізу даних на ланцюгу, але ці реалізації більше не будуть частиною основної специфікації консенсусу. Тоді механізм консенсусу Ethereum буде «рідним» лише для архітектури RISC-V.
Спрощення через компоненти спільного протоколу
Третій (і найбільш недооцінений) спосіб зменшити загальну складність протоколу полягає в тому, щоб максимально використовувати загальний стандарт на всіх рівнях стека. Загалом, не є ані необхідним, ані вигідним використання різних протоколів для досягнення однакової функціональності в різних модулях, але такі шаблони проектування все ще поширені, головним чином через відсутність ефективної координації між різними частинами дорожньої карти протоколу. Нижче наведено приклади конкретних сценаріїв, коли Ethereum можна спростити за допомогою зміцнення компонентів для крос-шарового мультиплексування.
Уніфіковане рішення зі спільного використання коду виправлення помилок
Три типи застосування коду корекції помилок:
Вибірка доступності даних: клієнт повинен використовувати кодування з корекцією помилок для перевірки, чи блок було опубліковано, щоб забезпечити цілісність даних.
Ефективне P2P транслювання: вузли можуть підтверджувати блок, отримавши n/2 фрагментів з n, досягаючи оптимального балансу між зниженням затримки та надмірністю.
Розподілене історичне зберігання: історичні дані Ethereum розділені на кілька блоків даних, що відповідає:
Кожен блок даних може бути незалежно перевірений
Будь-яка група з n/2 блоків даних може відновити залишок n/2 блоків даних.
Цей дизайн суттєво знижує ризик втрати даних в одному місці.
Якщо використовувати однаковий код для виправлення помилок (наприклад, код Ріда-Соломона, випадковий лінійний код тощо) у трьох наступних сценаріях, це принесе значні переваги:
Оптимізація коду;
Підвищення ефективності: коли вузол потребує завантажити фрагментні дані (а не повний блок) через певну ситуацію, ці дані можуть бути безпосередньо використані для інших сценаріїв, уникаючи повторної передачі;
Усі блоки даних у всіх сценаріях можна перевірити за допомогою кореневого хешу.
Якщо використовуються різні коди виправлення помилок, потрібно дотримуватися вимог сумісності: наприклад, у фрагментах вибірки доступності даних (DAS) можна одночасно використовувати горизонтальні коди Ріда-Соломона та вертикальні випадкові лінійні коди, але обидва коди повинні базуватися на одній скінченній області для виконання обчислень.
Уніфікований формат серіалізації
Поточний формат серіалізації Ethereum все ще знаходиться на напівнормалізованому етапі — дані можуть бути повторно серіалізовані в будь-який формат і розповсюджені, єдиним винятком є хеш підпису транзакції, для якого необхідно використовувати нормалізований формат для забезпечення узгодженості хешу. Проте в майбутньому ступінь нормалізації формату серіалізації буде подальше зміцнено, основними причинами цього є:
Абстракція облікового запису (EIP-7701): повний вміст транзакції буде повністю видимим для віртуальної машини (VM)
Високі обмеження газу: оскільки ліміт газу блоків підвищується, дані виконавчого рівня потрібно зберігати у структурі blob.
Коли відбудеться вказана трансформація, ми можемо скористатися цим моментом для уніфікації стандартів серіалізації трьох ключових рівнів Ethereum: (i) рівень виконання (ii) рівень консенсусу (iii) ABI викликів смарт-контрактів
Рекомендується використовувати формат серіалізації SSZ, SSZ має такі переваги:
Декодування є ефективним, включаючи сценарії зі смарт-контрактами, які можуть бути швидко декодовані завдяки його дизайну на основі 4 байтів та меншій кількості обробки граничних умов.
Застосування на рівні консенсусу широко використовується, вже на рівні консенсусу реалізована глибока інтеграція.
Дуже схожий на існуючий ABI, що спрощує оновлення адаптації інструментального забезпечення.
Наразі вже є відповідні технічні команди, які просувають всебічну міграцію SSZ. Рекомендується продовжити цей технічний шлях у подальших планах оновлення та розширити на основі наявних досягнень.
Уніфікована спільна деревоподібна структура
Після переходу з EVM на RISC-V (або іншу спрощену архітектуру віртуальної машини) шісткове дерево Меркла Патріції стане найбільшим вузьким місцем продуктивності доказу виконання блоку (навіть у звичайних сценаріях). Перехід на двійкову структуру дерева з кращими хеш-функціями суттєво підвищить ефективність доказу та знизить витрати на зберігання даних для легких вузлів та інших сценаріїв.
При реалізації цього переходу слід одночасно використовувати ту ж дерево-подібну структуру для досягнення єдності між рівнем консенсусу та рівнем виконання. Цей крок забезпечить, що весь стек Ethereum (включаючи рівень консенсусу та рівень виконання) використовує одну й ту ж логіку коду для доступу до даних та їх розбору.
Еволюційний шлях від поточного стану до цілі
Простота багато в чому схожа на децентралізацію, і обидва є фундаментальними передумовами для стійкості системи. Чітке прийняття простоти як основної цінності вимагає культурних змін: переваги часто не очевидні відразу, тоді як короткострокові вигоди від ускладнень очевидні. Однак з часом переваги простоти стануть більш очевидними - і історія Bitcoin є тому підтвердженням.
Я пропоную використовувати практичний досвід проекту TinyGrad як основу для дизайну протоколу Ethereum, щоб встановити чіткі цілі щодо максимального числа рядків коду для довгострокових стандартів Ethereum, прагнучи наблизити рівень простоти ключового коду консенсусу Ethereum до рівня Bitcoin. Зокрема, код, що стосується історичних правил Ethereum, може бути збережений, але має бути суворо ізольований від ключових шляхів консенсусу, щоб забезпечити його без впливу на основну логіку консенсусу; при цьому в виборі технічних рішень слід дотримуватися принципу «переваги простіших рішень», віддаючи перевагу інкапсуляції складності, а не розширенню системної складності, і забезпечуючи, щоб усі проектні рішення мали зрозумілі та перевіряємі характеристики й гарантії, створюючи в цілому технічну культуру, орієнтовану на простоту.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Віталік нова стаття: як Ethereum реалізує спрощену архітектуру, що відповідає Біткойну?
Оригінальна назва: Спрощення L1
Автор: Віталік
Компіляція: lenaxin, ChainCatcher
Ethereum має на меті стати світовою книгою обліку: платформою для зберігання цивілізаційних активів і записів, основою для фінансів, управління, сертифікації даних з високою доданою вартістю тощо. Це вимагає виконання двох умов: масштабованості та стійкості. Хардфорк Fusaka має на меті збільшити доступний обсяг даних другого рівня (L2) у 10 разів, а поточна запланована дорожня карта на 2026 рік також пропонує подібне значне розширення першого рівня (L1). Тим часом, Ethereum завершив оновлення до механізму доказу частки (Proof of Stake), різноманітність його клієнтів швидко зростає, триває робота в напрямку перевірки нульових знань (ZK Verifiability) та стійкості до квантових обчислень, а також різні застосунки стають дедалі надійнішими.
Ця стаття має на меті зосередитися на одному з аспектів стійкості (яка в кінцевому підсумку також вплине на масштабованість), який є не менш важливим, але його легко недооцінити, а саме на простоті протоколу.
Однією з великих переваг біткоїна є його надзвичайно простий та елегантний протокол.
Блокчейн складається з серії блоків, кожен з яких з'єднаний з попереднім блоком за допомогою хешу. Валідність блоку перевіряється механізмом proof-of-work, тобто перевіряється, що перші кілька цифр його хеш-значення дорівнюють нулю. Кожен блок містить кількість транзакцій, які споживають монети, які або видобуваються, або отримані в результаті виведення попередніх транзакцій. Саме в цьому полягає основний механізм протоколу Bitcoin. Навіть здібні учні середніх класів можуть повністю розуміти цей протокол, а програмісти навіть можуть писати клієнтам як аматорські проекти.
Збереження простоти протоколу забезпечує ключову перевагу для того, щоб біткойн або ефір стали глобально визнаним нейтральним базовим рівнем:
Простіші протоколи легше аналізувати, що може залучити більше учасників до дослідження, розробки та управління протоколами, а також знизити ризик технологічної монополії.
Спрощена структура протоколу суттєво зменшує витрати на розробку інтеграції з новою інфраструктурою (такою як клієнти, доказники, інструменти журналювання та інші розробницькі інструменти).
Простий дизайн угоди ефективно знижує довгострокові витрати на обслуговування.
Серйозні ризики вразливості в специфікаціях протоколу та їх реалізації значно зменшено, що полегшує перевірку безпеки системи.
Зменшення соціальної атаки: спростження компонентів робить систему легшою для захисту від проникнення спеціальних інтересів, підвищуючи загальну безпеку.
Протягом історії Ethereum часто не вдалося реалізувати принципи простоти в проектуванні протоколу (частково через мої рішення), що безпосередньо призвело до високих витрат на розробку, частих загроз безпеці та закритості культури розробки. Корені цих проблем часто полягають у прагненні до короткострокових вигод, які виявилися недійсними на практиці. У цій статті буде розглянуто, як Ethereum може досягти близькості до простоти протоколу Bitcoin протягом наступних п'яти років.
Спрощений рівень консенсусу
Моделювання фіналізації трьох часових слотів у 3sf - mini (кодова назва тестової мережі Ethereum)
Нова версія рішення для рівня консенсусу (раніше відома як «Світловий ланцюг») має на меті інтеграцію досягнень досліджень за останнє десятиліття в галузях теорії консенсусу, нульових знань (ZK-SNARK), економіки стейкингу та інших, щоб створити оптимальний механізм консенсусу для Ethereum, орієнтуючи його на довгостроковий розвиток. У порівнянні з існуючою Beacon Chain, це рішення має значно спрощені характеристики, що виявляються в наступних аспектах:
Трьохслотова фінальність (3-slot finality) архітектурна інновація: усунула концептуальне розділення незалежних слотів (slot) та епох (epoch), скасувала механізм ротації комітету та складні компоненти синхронного комітету, значно спростивши протокол. Основна реалізація потребує лише близько 200 рядків коду, досягаючи майже оптимального рівня безпеки в порівнянні з протоколом Gasper.
Оптимізація управління валідаційними вузлами: обмежуючи кількість активних валідаційних вузлів, можна реалізувати спрощене рішення для правил вибору розгалуження (fork choice rule), при цьому забезпечуючи безпеку системи.
Оновлення агрегаційного протоколу: механізм агрегації на основі STARK дозволяє будь-якому вузлу виконувати роль агрегації, уникаючи залежності від довіри до агрегатора та проблеми витрат ресурсів через повторювані бітові поля (bitfield). Незважаючи на те, що сама агрегаційна криптографія є досить складною, її висока ступінь інкапсуляції суттєво знижує системні ризики.
Покращення архітектури P2P-мережі: вказані вище два оптимізації створили можливості для побудови більш простої та ефективної архітектури точка-точка.
Реконструкція процесу верифікації: повторний дизайн механізмів допуску, виходу, зняття коштів, міграції ключів та покарання за бездіяльність в той час, коли зменшується обсяг коду, та чітке визначення механізму забезпечення основних параметрів (таких як період слабкої суб'єктивності).
Технічні переваги: відносна декомпозиція між рівнем консенсусу та рівнем виконання EVM забезпечує більший технічний простір для безперервної оптимізації. У порівнянні з цим, аналогічні вдосконалення на рівні виконання стикаються з більшими викликами.
Спрощений рівень виконання
Складність віртуальної машини Ethereum (EVM) продовжує зростати, при цьому багато складних дизайнів виявилися непотрібними (у багатьох випадках це були мої помилки в ухваленні рішень): 256-бітна віртуальна машина, надмірно оптимізована для певного криптографічного алгоритму, який наразі поступово втрачає свою важливість; а також надмірно розроблені попередньо скомпільовані контракти для єдиного сценарію використання, фактична використання яких є вкрай низькою.
Спроби вирішити існуючі проблеми шляхом фрагментарних виправлень стали неможливими. Видалення операційного коду SELFDESTRUCT вимагало величезних зусиль, але принесло лише обмежені результати, а нещодавні суперечки щодо EOF ще більше підкреслили труднощі поступових змін у віртуальній машині.
В якості альтернативи я нещодавно запропонував більш радикальний шлях трансформації: замість того, щоб робити середню (але все ще руйнівну) модифікацію EVM в обмін на 1,5-кратний приріст продуктивності, я б просто перейшов на нову і значно кращу архітектуру віртуальних машин для стрибка продуктивності в стократний раз. Подібно до The Merge, ми збільшуємо стратегічну цінність кожної зміни, зменшуючи кількість непрацюючих змін. Зокрема, рекомендується замінити існуючий EVM на архітектуру RISC-V або віртуальну машину, яка використовується програмою доказу Ethereum ZK. Ця трансформація принесе:
Революційне підвищення ефективності: у середовищі ZK-доказів смарт-контракти можуть безпосередньо працювати на цільовій архітектурі без витрат на інтерпретатор. Стислі дані показують, що у більшості сценаріїв продуктивність може зростати більш ніж у сто разів.
Архітектура максимально спрощена: специфікація RISC-V є значно більш стиснутою в порівнянні з EVM, інші кандидатні рішення (наприклад, Cairo) також мають прості характеристики.
Спадкування основних переваг EOF: включає в себе управління сегментацією коду, більш дружню підтримку статичного аналізу та більші обмеження на обсяг коду.
Розширення інструментів для розробників: Solidity та Vyper можуть додати підтримку нових архітектур через нову компіляцію на стороні сервера; якщо вибрати RISC-V, розробники основних мов можуть безпосередньо переносити існуючий код.
Оптимізація попередньо скомпільованих контрактів: більшість функцій попередньо скомпільованих контрактів більше не буде необхідна, залишаться лише високоефективні обчислення еліптичних кривих (можуть бути усунуті внаслідок розвитку квантових обчислень).
Основним викликом є те, що, на відміну від рішень EOF, які можуть бути реалізовані негайно, новій віртуальній машині потрібен більше часу, щоб принести користь розробникам. Можна реалізувати частину цінних покращень EVM (наприклад, підвищення обмеження розміру коду контракту, оптимізація набору інструкцій DUP/SWAP) як короткострокове перехідне рішення.
Ця трансформація суттєво спростить архітектуру віртуальної машини. Основне питання полягає в тому: як належним чином обробити існуючу екосистему EVM?
Стратегія зворотної сумісності для міграції віртуальних машин
最大ним викликом спростити (або оптимізувати, не збільшуючи складність) будь-яку частину EVM є балансування між досягненням очікуваних цілей і підтримкою зворотної сумісності з існуючими застосунками.
По-перше, необхідно чітко визначити: навіть для одного клієнта немає єдиного стандарту для визначення того, що таке «кодова база Ethereum».
Мета полягає в мінімізації зеленої області: тобто вузол виконує логіку, необхідну для участі в консенсусі Ethereum, включаючи обчислення поточного стану, генерацію та перевірку доказів, FOCIL (примітка: потрібно підтвердити, чи є це абревіатурою професійного терміна) та процес побудови «базового» блоку.
Помаранчева зона не може бути зменшена: якщо функції виконувального шару (незалежно від того, чи це віртуальна машина, попередньо скомпільований контракт або інші механізми) будуть видалені з протокольних специфікацій або їх функціональність зміниться, клієнти, які обробляють історичні блоки, повинні зберегти цю функцію; але нові клієнти (включаючи ZK-EVM або інструменти формальної верифікації) можуть повністю ігнорувати цю частину.
Новий жовтий сектор: це код, який має велике значення для аналізу даних на поточному ланцюзі або оптимального побудови блоків, але не належить до механізму консенсусу. Типовими прикладами є підтримка операцій користувачів ERC-4337 з боку Etherscan та деяких будівельників блоків. Якщо замінити основні функції Ethereum (такі як зовнішні рахунки EOA та різні старі типи транзакцій, які вони підтримують) на реалізацію RISC-V на ланцюзі, код консенсусу суттєво спроститься, але спеціалізовані вузли можуть все ще потребувати використання оригінального коду для обробки аналізу.
Складність оранжевої та жовтої зон належить до складності упаковки, будь-яка особа, що бажає зрозуміти протокол, може пропустити ці частини, а рішення реалізації Ethereum може вільно вибрати ігнорувати їх. Крім того, дефекти коду в цих зонах не викликають ризику консенсусу. Це означає, що, порівняно зі складністю коду в зеленій зоні, складність оранжевої та жовтої зон має значно менший негативний вплив на загальну систему.
Ідея перенесення коду з зеленої зони в жовту зону подібна до технічного рішення Apple, яке реалізує тривалу зворотну сумісність за допомогою шару перекладу Rosetta.
Вимога, щоб усі нові розроблені попередньо скомпільовані контракти обов'язково містили нормативну реалізацію RISC-V на ланцюгу. Цей крок має на меті поступове адаптування екосистеми до середовища віртуальної машини RISC-V (з прикладом переходу від EVM до RISC-V, це рішення також підходить для міграції з EVM до Cairo або інших більш оптимальних віртуальних машин):
Подвійна підтримка віртуальних машин: на рівні протоколу одночасно нативно підтримуються дві віртуальні машини RISC-V та EVM. Розробники можуть вільно обирати мову програмування, контракти, написані для різних віртуальних машин, можуть безперешкодно взаємодіяти.
Покрокова заміна попередньо скомпільованих контрактів: усі попередньо скомпільовані контракти, крім операцій з еліптичними кривими та алгоритму хешування KECCAK (через їхнє екстремальне оптимізування для продуктивності), будуть замінені на реалізацію RISC-V через жорсткий форк.
Конкретні дії полягають у тому, щоб одночасно видалити первісний попередньо скомпільований контракт, а також змінити код за цією адресою (з використанням моделі DAO fork) з порожнього стану на відповідну реалізацію RISC-V. Завдяки високій простоті архітектури RISC-V, навіть якщо виконати лише цей крок, загальна складність системи все ще зменшиться.
Впровадження EVM-інтерпретатора на блокчейні: реалізація EVM-інтерпретатора на базі RISC-V (інструментальний набір ZK-доказів вже сприяв такій розробці) і його розгортання в якості смарт-контракту на блокчейні. Через кілька років після випуску початкової версії, існуючі EVM-контракти будуть виконуватися за допомогою цього інтерпретатора, що забезпечить плавний перехід на нову віртуальну машину.
Спрощення шляхом реалізації компонентів спільного протоколу
Після завершення четвертого етапу безліч «EVM-рішень» залишаться і будуть використовуватись для оптимізації побудови блоків, інструментів для розробників та аналізу даних на ланцюгу, але ці реалізації більше не будуть частиною основної специфікації консенсусу. Тоді механізм консенсусу Ethereum буде «рідним» лише для архітектури RISC-V.
Спрощення через компоненти спільного протоколу
Третій (і найбільш недооцінений) спосіб зменшити загальну складність протоколу полягає в тому, щоб максимально використовувати загальний стандарт на всіх рівнях стека. Загалом, не є ані необхідним, ані вигідним використання різних протоколів для досягнення однакової функціональності в різних модулях, але такі шаблони проектування все ще поширені, головним чином через відсутність ефективної координації між різними частинами дорожньої карти протоколу. Нижче наведено приклади конкретних сценаріїв, коли Ethereum можна спростити за допомогою зміцнення компонентів для крос-шарового мультиплексування.
Уніфіковане рішення зі спільного використання коду виправлення помилок
Три типи застосування коду корекції помилок:
Вибірка доступності даних: клієнт повинен використовувати кодування з корекцією помилок для перевірки, чи блок було опубліковано, щоб забезпечити цілісність даних.
Ефективне P2P транслювання: вузли можуть підтверджувати блок, отримавши n/2 фрагментів з n, досягаючи оптимального балансу між зниженням затримки та надмірністю.
Розподілене історичне зберігання: історичні дані Ethereum розділені на кілька блоків даних, що відповідає:
Кожен блок даних може бути незалежно перевірений
Будь-яка група з n/2 блоків даних може відновити залишок n/2 блоків даних.
Цей дизайн суттєво знижує ризик втрати даних в одному місці.
Якщо використовувати однаковий код для виправлення помилок (наприклад, код Ріда-Соломона, випадковий лінійний код тощо) у трьох наступних сценаріях, це принесе значні переваги:
Оптимізація коду;
Підвищення ефективності: коли вузол потребує завантажити фрагментні дані (а не повний блок) через певну ситуацію, ці дані можуть бути безпосередньо використані для інших сценаріїв, уникаючи повторної передачі;
Усі блоки даних у всіх сценаріях можна перевірити за допомогою кореневого хешу.
Якщо використовуються різні коди виправлення помилок, потрібно дотримуватися вимог сумісності: наприклад, у фрагментах вибірки доступності даних (DAS) можна одночасно використовувати горизонтальні коди Ріда-Соломона та вертикальні випадкові лінійні коди, але обидва коди повинні базуватися на одній скінченній області для виконання обчислень.
Уніфікований формат серіалізації
Поточний формат серіалізації Ethereum все ще знаходиться на напівнормалізованому етапі — дані можуть бути повторно серіалізовані в будь-який формат і розповсюджені, єдиним винятком є хеш підпису транзакції, для якого необхідно використовувати нормалізований формат для забезпечення узгодженості хешу. Проте в майбутньому ступінь нормалізації формату серіалізації буде подальше зміцнено, основними причинами цього є:
Абстракція облікового запису (EIP-7701): повний вміст транзакції буде повністю видимим для віртуальної машини (VM)
Високі обмеження газу: оскільки ліміт газу блоків підвищується, дані виконавчого рівня потрібно зберігати у структурі blob.
Коли відбудеться вказана трансформація, ми можемо скористатися цим моментом для уніфікації стандартів серіалізації трьох ключових рівнів Ethereum: (i) рівень виконання (ii) рівень консенсусу (iii) ABI викликів смарт-контрактів
Рекомендується використовувати формат серіалізації SSZ, SSZ має такі переваги:
Декодування є ефективним, включаючи сценарії зі смарт-контрактами, які можуть бути швидко декодовані завдяки його дизайну на основі 4 байтів та меншій кількості обробки граничних умов.
Застосування на рівні консенсусу широко використовується, вже на рівні консенсусу реалізована глибока інтеграція.
Дуже схожий на існуючий ABI, що спрощує оновлення адаптації інструментального забезпечення.
Наразі вже є відповідні технічні команди, які просувають всебічну міграцію SSZ. Рекомендується продовжити цей технічний шлях у подальших планах оновлення та розширити на основі наявних досягнень.
Уніфікована спільна деревоподібна структура
Після переходу з EVM на RISC-V (або іншу спрощену архітектуру віртуальної машини) шісткове дерево Меркла Патріції стане найбільшим вузьким місцем продуктивності доказу виконання блоку (навіть у звичайних сценаріях). Перехід на двійкову структуру дерева з кращими хеш-функціями суттєво підвищить ефективність доказу та знизить витрати на зберігання даних для легких вузлів та інших сценаріїв.
При реалізації цього переходу слід одночасно використовувати ту ж дерево-подібну структуру для досягнення єдності між рівнем консенсусу та рівнем виконання. Цей крок забезпечить, що весь стек Ethereum (включаючи рівень консенсусу та рівень виконання) використовує одну й ту ж логіку коду для доступу до даних та їх розбору.
Еволюційний шлях від поточного стану до цілі
Простота багато в чому схожа на децентралізацію, і обидва є фундаментальними передумовами для стійкості системи. Чітке прийняття простоти як основної цінності вимагає культурних змін: переваги часто не очевидні відразу, тоді як короткострокові вигоди від ускладнень очевидні. Однак з часом переваги простоти стануть більш очевидними - і історія Bitcoin є тому підтвердженням.
Я пропоную використовувати практичний досвід проекту TinyGrad як основу для дизайну протоколу Ethereum, щоб встановити чіткі цілі щодо максимального числа рядків коду для довгострокових стандартів Ethereum, прагнучи наблизити рівень простоти ключового коду консенсусу Ethereum до рівня Bitcoin. Зокрема, код, що стосується історичних правил Ethereum, може бути збережений, але має бути суворо ізольований від ключових шляхів консенсусу, щоб забезпечити його без впливу на основну логіку консенсусу; при цьому в виборі технічних рішень слід дотримуватися принципу «переваги простіших рішень», віддаючи перевагу інкапсуляції складності, а не розширенню системної складності, і забезпечуючи, щоб усі проектні рішення мали зрозумілі та перевіряємі характеристики й гарантії, створюючи в цілому технічну культуру, орієнтовану на простоту.