Ефіріум має на меті стати глобальним реєстром, що вимагає масштабованості та стійкості. У цій статті акцентується важливість простоти протоколу, пропонується значно знизити складність шляхом спрощення шару консенсусу (3-slot остаточність, STARK агрегація) та виконавчого шару (заміна EVM на RISC-V або подібну віртуальну машину), зменшуючи витрати на розробку, ризики помилок та поверхню атаки. Рекомендується плавний перехід через стратегію зворотної сумісності (наприклад, інтерпретатор EVM на ланцюгу) та уніфікація кодування з виправленням помилок, форматів серіалізації (SSZ) та деревоподібної структури для подальшого спрощення. Мета полягає в тому, щоб наблизити ключовий код консенсусу Ефіріума до простоти Біткоїна, підвищуючи стійкість та залученість, при цьому культурно акцентуючи увагу на простоті та встановлюючи максимальну цільову кількість рядків коду.
Мета Ethereum – стати глобальною книгою: платформою для зберігання активів і записів людської цивілізації, що обслуговує сфери фінансів, управління та сертифікації цінних даних. Для цього потрібні два стовпи: масштабованість і відмовостійкість. Планується, що хардфорк Fusaka збільшить доступний простір для даних L2 в 10 разів, а запропонована в даний час дорожня карта до 2026 року планує принести аналогічний значний приріст рівня L1. У той же час Ethereum завершив перехід на proof-of-stake (PoS), різноманітність клієнтів стрімко зросла, верифікація з нульовим розголошенням (ZK) і дослідження квантової стійкості також неухильно просуваються, а екосистема додатків стає все більш стабільною.
Ця стаття має на меті зосередитися на ще одному важливому, але часто недооцінюваному елементі стійкості (а також масштабованості): простоті протоколу.
Найбільш вражаючою рисою протоколу Біткоїна є його елегантна простота:
Існує ланцюг, що складається з блоків, кожен з яких з'єднаний з попереднім блоком за допомогою хешу.
Дійсність блоку перевіряється через доказ роботи (PoW), тобто перевіряється, чи є перші кілька цифр хеш-значення нулями.
Кожен блок містить транзакції, монети, витрачені в транзакціях, або надходять з винагороди за видобуток, або з виходу попередніх транзакцій.
Це все! Навіть розумний учень старшої школи може повністю зрозуміти роботу протоколу біткоїнів, а програміст навіть може написати клієнт як хобі.
Простота угоди надала безліч ключових переваг біткойну (та ефіріуму) для того, щоб стати надійним, нейтральним глобальним основним рівнем:
Легко зрозуміти: зменшити складність протоколу, щоб більше людей могли брати участь у дослідженні, розробці та управлінні протоколом, зменшуючи ризики, пов'язані з домінуванням технічної еліти.
Зниження витрат на розробку: спрощення протоколу суттєво знижує вартість створення нової інфраструктури (такої як нові клієнти, доказчики, інструменти для розробників тощо).
Зменшення витрат на обслуговування: зниження витрат на підтримку довгострокових угод.
Зменшення ризику помилок: зменшення ймовірності виникнення катастрофічних помилок у специфікаціях і реалізації протоколу, а також полегшення перевірки відсутності таких помилок.
Зменшення атакувальної поверхні: зменшити складні компоненти протоколу, знизити ризик атак з боку спеціальних інтересів.
В історії Ethereum (іноді через мої особисті рішення) часто не вдавалося зберегти простоту, що призводило до надмірних витрат на розробку, збільшення ризиків безпеки та закритості культури досліджень і розробок, а вигоди від цього прагнення до складності часто виявлялися ілюзорними. У цій статті буде розглянуто, як через п’ять років Ethereum наблизиться до простоти Bitcoin.
Спрощений рівень консенсусу
Новий дизайн шару консенсусу (історично відомий як "маяковий ланцюг") має на меті використати досвід останнього десятиліття в теорії консенсусу, розробці ZK-SNARK, економіці стейкінгу та інших сферах для створення довгострокового оптимального та простішого шару консенсусу. У порівнянні з існуючим маяковим ланцюгом, новий дизайн значно спростив:
Дизайн з трьома слотами для остаточної версії: видалити концепції слоту (slot), епохи (epoch), реорганізації комітету та пов'язані з ними механізми ефективної обробки (як-от синхронні комітети). Базова реалізація остаточної версії з трьома слотами потребує лише близько 200 рядків коду, а безпека близька до оптимальної в порівнянні з Gasper.
Зменшення кількості активних валідаторів: дозволити використовувати простіші правила вибору розгалуження для досягнення більшої безпеки.
Протокол агрегації на основі STARK: будь-хто може стати агретором, не довіряючи агретору або не сплачуючи високі витрати за повторні розміри. Складність агрегаційної криптографії досить висока, але її складність сильно інкапсульована, а системний ризик є низьким.
Спрощена P2P архітектура: зазначені фактори можуть сприяти більш простій та надійній архітектурі точка-точка.
Переробка механізму валідаторів: включаючи механізми входу, виходу, зняття коштів, зміни ключів, витоку неактивності тощо, спростити кількість рядків коду та надати чіткіші гарантії (наприклад, період слабкої суб'єктивності).
Переваги рівня консенсусу полягають у його відносній незалежності від рівня виконання EVM, що забезпечує більший простір для постійних покращень. Більшим викликом є те, як досягти подібного спрощення на рівні виконання.
Спрощений рівень виконання
Складність EVM постійно зростає, і багато з цих складнощів виявилися непотрібними (частково через мої особисті помилки у прийнятті рішень): 256-бітна віртуальна машина надмірно оптимізувала вже застарілі специфічні форми криптографії, а попередньо скомпільовані (precompiles) оптимізовані для єдиного випадку рідко використовуються.
Покрокове вирішення цих проблем має обмежену ефективність. Наприклад, видалення оператора SELFDESTRUCT вимагає величезних зусиль, але приносить лише незначну вигоду. Нещодавні суперечки навколо EOF (формат об'єктів EVM) також вказують на подібні виклики.
Нещодавно я висунув більш радикальну пропозицію: замість середньомасштабних (але все ще руйнівних) змін у EVM заради 1,5-кратної вигоди, краще перейти на більш оптимальну та просту віртуальну машину для досягнення 100-кратної вигоди. Подібно до "злиття" (The Merge), ми зменшуємо кількість руйнівних змін, але робимо кожну зміну більш значущою. Конкретно, я пропоную замінити EVM на RISC-V або на іншу віртуальну машину, яку використовує zk-протокол Ethereum. Це призведе до:
Значне підвищення ефективності: виконання смарт-контрактів (в доказувачі) відбувається без накладних витрат на інтерпретатор, виконується безпосередньо. Дані Succinct показують, що в багатьох сценаріях продуктивність може підвищитися більше ніж у 100 разів.
Значне полегшення: специфікація RISC-V надзвичайно проста в порівнянні з EVM, аналогічні альтернативи (такі як Cairo) також прості.
Мотиви підтримки EOF: такі як розділення коду, більш дружній статичний аналіз, більші обмеження на розмір коду тощо.
Більше варіантів для розробників: Solidity та Vyper можуть додавати бекенд для компіляції в нову віртуальну машину. Якщо обрати RISC-V, розробники основних мов також можуть легко перенести код на цю віртуальну машину.
Видалити більшість попередньо скомпільованих: можливо, залишити лише високооптимізовані операції з еліптичними кривими (після поширення квантових комп'ютерів навіть ці операції зникнуть).
Основний недолік полягає в тому, що на відміну від готового EOF, новій віртуальній машині знадобиться більше часу, щоб принести вигоду розробникам. Ми можемо пом'якшити цю проблему, реалізуючи короткострокові високоякісні покращення EVM (такі як збільшення обмеження на розмір коду контракту, підтримка DUP/SWAP17–32).
Це призведе до більш простої віртуальної машини. Основний виклик полягає в тому: як впоратися з існуючим EVM?
Стратегія зворотної сумісності для переходу віртуальної машини
Основним викликом спрощення (або покращення без ускладнення) EVM є балансування між досягненням цілей та зворотною сумісністю з існуючими додатками.
По-перше, необхідно чітко усвідомити: кодова база Ethereum (навіть в межах одного клієнта) не має лише одного способу визначення.
Метою є максимально зменшити зелену зону: логіка, необхідна для участі вузлів у консенсусі Ethereum, включаючи обчислення поточного стану, доведення, перевірку, FOCIL (правила вибору розгалуження) та будівництво "звичайних" блоків.
Помаранчева зона не може бути зменшена: якщо специфікація протоколу видаляє або змінює певні функції виконувального шару (такі як віртуальна машина, попередня компіляція тощо), клієнти, що обробляють історичні блоки, все ще повинні зберігати відповідний код. Але нові клієнти, ZK-EVM або формальні доведення можуть повністю ігнорувати помаранчеву зону.
Новий жовтий сектор: дуже цінний для розуміння поточного ланцюга або оптимізації побудови блоків, але не належить до логіки консенсусу. Наприклад, Etherscan і деякі будівельники блоків підтримують операції користувачів ERC-4337. Якщо ми замінимо деякі функції Ethereum (такі як EOA і підтримувані ним старі типи транзакцій) реалізацією RISC-V в ланцюзі, код консенсусу значно спроститься, але спеціалізовані вузли можуть продовжувати використовувати оригінальний код для аналізу.
Складність оранжевої та жовтої зон є упаковкою складності, і ті, хто розуміє протокол, можуть пропустити ці частини, Ethereum може їх ігнорувати, помилки в цих зонах не спричинять ризику консенсусу. Тому, кодова складність оранжевої та жовтої зон значно менш небезпечна, ніж складність зеленої зони.
Переміщення коду з зеленої області в жовту область нагадує стратегію Apple забезпечити довгострокову зворотну сумісність через шар перекладу Rosetta.
Натхнений недавньою статтею команди Ipsilon, я пропоную наступний процес змін віртуальної машини (на прикладі EVM до RISC-V, але також може бути використаний для EVM до Cairo або RISC-V до більш оптимальної віртуальної машини):
Вимагати нову попередньо скомпільовану версію, яка надає реалізацію RISC-V в ланцюзі: дати можливість екосистемі поступово адаптуватися до віртуальної машини RISC-V.
Введення RISC-V як варіанту для розробників: протокол підтримує як RISC-V, так і EVM, контракти обох віртуальних машин можуть вільно взаємодіяти.
Замінити більшість попередньо скомпільованих: окрім операцій з еліптичними кривими та KECCAK (через необхідність екстремальної швидкості), реалізувати заміну інших попередньо скомпільованих за допомогою RISC-V. Видалити попередньо скомпільовані через жорсткий форк, одночасно змінивши код цієї адреси (аналогічно форку DAO) з порожнього на реалізацію RISC-V. Віртуальна машина RISC-V надзвичайно проста, навіть на цьому етапі вже суттєво спрощує протокол.
Реалізація EVM інтерпретатора в RISC-V: як смарт-контракт на ланцюзі (оскільки ZK-програміст потребує завершення). Після кількох років з моменту початкового випуску існуючі EVM контракти виконуються через цей інтерпретатор.
Після завершення 4-го етапу багато "EVM реалізацій" все ще будуть використовуватися для оптимізації побудови блоків, інструментів для розробників та аналізу ланцюга, але більше не будуть частиною ключових стандартів консенсусу. Консенсус Ethereum буде "рідним" лише для RISC-V.
Спрощення через компоненти спільного протоколу
Третій спосіб зниження загальної складності протоколу (також найчастіше недооцінюваний) полягає в тому, щоб якомога більше ділитися єдиними стандартами в різних частинах стеку протоколів. Різні протоколи, які виконують одну й ту саму функцію в різних сценаріях, зазвичай не приносять ніякої користі, але ця модель все ж часто виникає, в основному через брак комунікації між різними частинами дорожньої карти протоколів. Ось кілька конкретних прикладів спрощення Ethereum через спільні компоненти.
Уніфікований код для видалення
Ми потребуємо кодів корекції та видалення в трьох сценаріях:
Вибірка доступності даних: клієнт перевіряє, чи блок був опублікований.
Швидша P2P трансляція: вузол може приймати блок після отримання n/2 фрагментів, досягаючи балансу між затримкою та надмірністю.
Розподілене історичне зберігання: фрагментація історичних даних Ethereum, кожна група з n/2 фрагментів може відновити інші фрагменти, що знижує ризик втрати окремого фрагмента.
Якщо використовувати один і той же код корекції помилок (незалежно від того, чи це код Ріда-Соломона, випадковий лінійний код тощо) у трьох різних сценаріях, ви отримаєте такі переваги:
Мінімізуйте обсяг коду: зменшіть загальну кількість рядків коду.
Підвищення ефективності: якщо вузол завантажує частину фрагментів для певного сценарію, ці дані можуть бути використані для інших сценаріїв.
Забезпечте перевірність: усі фрагменти сцен можна перевірити відповідно до кореня.
Якщо використовуються різні коди корекції помилок, принаймні, слід забезпечити їхню сумісність, наприклад, код Ріда-Соломона для вибірки доступності даних на горизонтальному рівні та вертикальний випадковий лінійний код, що працюють в одній області.
Уніфікований формат серіалізації
Серіалізований формат Ethereum наразі лише частково зафіксований, оскільки дані можуть бути повторно серіалізовані та передані в будь-якому форматі. Винятком є хеш підпису транзакції, який повинен бути зафіксований у стандартному форматі для хешування. У майбутньому ступінь фіксації серіалізованого формату буде подальше підвищена з наступних причин:
Повна абстракція облікового запису (EIP-7701): повний зміст транзакції видимий для віртуальної машини.
Вищий ліміт Gas: дані виконавчого рівня повинні бути поміщені в блоки даних (blobs).
Тоді у нас буде можливість уніфікувати три рівні серіалізації Ethereum: рівень виконання, рівень консенсусу, ABI виклику смарт-контракту.
Я пропоную використовувати SSZ, оскільки SSZ:
Легко декодувати: включає в себе в смарт-контракті (оскільки він базується на дизайні з 4 байт і має менше крайніх випадків).
Широко використовується на рівні консенсусу.
Дуже схожий на існуючий ABI: адаптація інструментів відносно проста.
Вже ведуться зусилля щодо повної міграції на SSZ, і ми повинні враховувати та продовжувати ці зусилля при плануванні майбутніх оновлень.
Уніфікована деревоподібна структура
Якщо перейти з EVM на RISC-V (або інші можливі мінімальні віртуальні машини), шістнадцяткове Merkle Patricia дерево стане найбільшим обмеженням для підтвердження виконання блоків, навіть у середньому випадку. Перехід на бінарне дерево, засноване на більш оптимальних хеш-функціях, значно підвищить ефективність доказувача, одночасно зменшуючи витрати на дані в таких сценаріях, як легкі клієнти.
Під час міграції слід забезпечити використання однакової структури дерев у шарі консенсусу. Це дозволить шару консенсусу Ethereum отримувати доступ і аналізувати шар виконання за допомогою одного й того ж коду.
Від тепер до майбутнього
Простота в багатьох аспектах подібна до децентралізації, обидва є верхніми цілями стійкості. Чітке усвідомлення простоти вимагає певної культурної зміни. Її вигоди часто важко кількісно оцінити, тоді як витрати на додаткові зусилля та відмову від деяких вражаючих функцій проявляються негайно. Однак, з часом вигоди будуть ставати дедалі більш помітними — — сам Bitcoin є відмінним прикладом.
Я пропоную наслідувати tinygrad і встановити чітку максимальну цільову кількість рядків коду для довгострокових стандартів Ethereum, щоб ключовий код консенсусу Ethereum наблизився до простоти Bitcoin. Код, що обробляє історичні правила Ethereum, продовжуватиме існувати, але його слід розмістити поза ключовими шляхами консенсусу. Одночасно ми повинні дотримуватися принципу вибору простіших рішень, переважно обираючи інкапсуляцію складності, а не системну складність, і робити вибір дизайну, який забезпечує чіткі атрибути та гарантії.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Віталік Бутерін: Як зробити Ethereum через 5 років таким же простим, як Біткойн
Автор | Віталік Бутерін
Компільовано | GaryMa У сказав блокчейн
Оригінальне посилання:
Резюме
Ефіріум має на меті стати глобальним реєстром, що вимагає масштабованості та стійкості. У цій статті акцентується важливість простоти протоколу, пропонується значно знизити складність шляхом спрощення шару консенсусу (3-slot остаточність, STARK агрегація) та виконавчого шару (заміна EVM на RISC-V або подібну віртуальну машину), зменшуючи витрати на розробку, ризики помилок та поверхню атаки. Рекомендується плавний перехід через стратегію зворотної сумісності (наприклад, інтерпретатор EVM на ланцюгу) та уніфікація кодування з виправленням помилок, форматів серіалізації (SSZ) та деревоподібної структури для подальшого спрощення. Мета полягає в тому, щоб наблизити ключовий код консенсусу Ефіріума до простоти Біткоїна, підвищуючи стійкість та залученість, при цьому культурно акцентуючи увагу на простоті та встановлюючи максимальну цільову кількість рядків коду.
Мета Ethereum – стати глобальною книгою: платформою для зберігання активів і записів людської цивілізації, що обслуговує сфери фінансів, управління та сертифікації цінних даних. Для цього потрібні два стовпи: масштабованість і відмовостійкість. Планується, що хардфорк Fusaka збільшить доступний простір для даних L2 в 10 разів, а запропонована в даний час дорожня карта до 2026 року планує принести аналогічний значний приріст рівня L1. У той же час Ethereum завершив перехід на proof-of-stake (PoS), різноманітність клієнтів стрімко зросла, верифікація з нульовим розголошенням (ZK) і дослідження квантової стійкості також неухильно просуваються, а екосистема додатків стає все більш стабільною.
Ця стаття має на меті зосередитися на ще одному важливому, але часто недооцінюваному елементі стійкості (а також масштабованості): простоті протоколу.
Найбільш вражаючою рисою протоколу Біткоїна є його елегантна простота:
Існує ланцюг, що складається з блоків, кожен з яких з'єднаний з попереднім блоком за допомогою хешу.
Дійсність блоку перевіряється через доказ роботи (PoW), тобто перевіряється, чи є перші кілька цифр хеш-значення нулями.
Кожен блок містить транзакції, монети, витрачені в транзакціях, або надходять з винагороди за видобуток, або з виходу попередніх транзакцій.
Це все! Навіть розумний учень старшої школи може повністю зрозуміти роботу протоколу біткоїнів, а програміст навіть може написати клієнт як хобі.
Простота угоди надала безліч ключових переваг біткойну (та ефіріуму) для того, щоб стати надійним, нейтральним глобальним основним рівнем:
Легко зрозуміти: зменшити складність протоколу, щоб більше людей могли брати участь у дослідженні, розробці та управлінні протоколом, зменшуючи ризики, пов'язані з домінуванням технічної еліти.
Зниження витрат на розробку: спрощення протоколу суттєво знижує вартість створення нової інфраструктури (такої як нові клієнти, доказчики, інструменти для розробників тощо).
Зменшення витрат на обслуговування: зниження витрат на підтримку довгострокових угод.
Зменшення ризику помилок: зменшення ймовірності виникнення катастрофічних помилок у специфікаціях і реалізації протоколу, а також полегшення перевірки відсутності таких помилок.
Зменшення атакувальної поверхні: зменшити складні компоненти протоколу, знизити ризик атак з боку спеціальних інтересів.
В історії Ethereum (іноді через мої особисті рішення) часто не вдавалося зберегти простоту, що призводило до надмірних витрат на розробку, збільшення ризиків безпеки та закритості культури досліджень і розробок, а вигоди від цього прагнення до складності часто виявлялися ілюзорними. У цій статті буде розглянуто, як через п’ять років Ethereum наблизиться до простоти Bitcoin.
Спрощений рівень консенсусу
Новий дизайн шару консенсусу (історично відомий як "маяковий ланцюг") має на меті використати досвід останнього десятиліття в теорії консенсусу, розробці ZK-SNARK, економіці стейкінгу та інших сферах для створення довгострокового оптимального та простішого шару консенсусу. У порівнянні з існуючим маяковим ланцюгом, новий дизайн значно спростив:
Дизайн з трьома слотами для остаточної версії: видалити концепції слоту (slot), епохи (epoch), реорганізації комітету та пов'язані з ними механізми ефективної обробки (як-от синхронні комітети). Базова реалізація остаточної версії з трьома слотами потребує лише близько 200 рядків коду, а безпека близька до оптимальної в порівнянні з Gasper.
Зменшення кількості активних валідаторів: дозволити використовувати простіші правила вибору розгалуження для досягнення більшої безпеки.
Протокол агрегації на основі STARK: будь-хто може стати агретором, не довіряючи агретору або не сплачуючи високі витрати за повторні розміри. Складність агрегаційної криптографії досить висока, але її складність сильно інкапсульована, а системний ризик є низьким.
Спрощена P2P архітектура: зазначені фактори можуть сприяти більш простій та надійній архітектурі точка-точка.
Переробка механізму валідаторів: включаючи механізми входу, виходу, зняття коштів, зміни ключів, витоку неактивності тощо, спростити кількість рядків коду та надати чіткіші гарантії (наприклад, період слабкої суб'єктивності).
Переваги рівня консенсусу полягають у його відносній незалежності від рівня виконання EVM, що забезпечує більший простір для постійних покращень. Більшим викликом є те, як досягти подібного спрощення на рівні виконання.
Спрощений рівень виконання
Складність EVM постійно зростає, і багато з цих складнощів виявилися непотрібними (частково через мої особисті помилки у прийнятті рішень): 256-бітна віртуальна машина надмірно оптимізувала вже застарілі специфічні форми криптографії, а попередньо скомпільовані (precompiles) оптимізовані для єдиного випадку рідко використовуються.
Покрокове вирішення цих проблем має обмежену ефективність. Наприклад, видалення оператора SELFDESTRUCT вимагає величезних зусиль, але приносить лише незначну вигоду. Нещодавні суперечки навколо EOF (формат об'єктів EVM) також вказують на подібні виклики.
Нещодавно я висунув більш радикальну пропозицію: замість середньомасштабних (але все ще руйнівних) змін у EVM заради 1,5-кратної вигоди, краще перейти на більш оптимальну та просту віртуальну машину для досягнення 100-кратної вигоди. Подібно до "злиття" (The Merge), ми зменшуємо кількість руйнівних змін, але робимо кожну зміну більш значущою. Конкретно, я пропоную замінити EVM на RISC-V або на іншу віртуальну машину, яку використовує zk-протокол Ethereum. Це призведе до:
Значне підвищення ефективності: виконання смарт-контрактів (в доказувачі) відбувається без накладних витрат на інтерпретатор, виконується безпосередньо. Дані Succinct показують, що в багатьох сценаріях продуктивність може підвищитися більше ніж у 100 разів.
Значне полегшення: специфікація RISC-V надзвичайно проста в порівнянні з EVM, аналогічні альтернативи (такі як Cairo) також прості.
Мотиви підтримки EOF: такі як розділення коду, більш дружній статичний аналіз, більші обмеження на розмір коду тощо.
Більше варіантів для розробників: Solidity та Vyper можуть додавати бекенд для компіляції в нову віртуальну машину. Якщо обрати RISC-V, розробники основних мов також можуть легко перенести код на цю віртуальну машину.
Видалити більшість попередньо скомпільованих: можливо, залишити лише високооптимізовані операції з еліптичними кривими (після поширення квантових комп'ютерів навіть ці операції зникнуть).
Основний недолік полягає в тому, що на відміну від готового EOF, новій віртуальній машині знадобиться більше часу, щоб принести вигоду розробникам. Ми можемо пом'якшити цю проблему, реалізуючи короткострокові високоякісні покращення EVM (такі як збільшення обмеження на розмір коду контракту, підтримка DUP/SWAP17–32).
Це призведе до більш простої віртуальної машини. Основний виклик полягає в тому: як впоратися з існуючим EVM?
Стратегія зворотної сумісності для переходу віртуальної машини
Основним викликом спрощення (або покращення без ускладнення) EVM є балансування між досягненням цілей та зворотною сумісністю з існуючими додатками.
По-перше, необхідно чітко усвідомити: кодова база Ethereum (навіть в межах одного клієнта) не має лише одного способу визначення.
Метою є максимально зменшити зелену зону: логіка, необхідна для участі вузлів у консенсусі Ethereum, включаючи обчислення поточного стану, доведення, перевірку, FOCIL (правила вибору розгалуження) та будівництво "звичайних" блоків.
Помаранчева зона не може бути зменшена: якщо специфікація протоколу видаляє або змінює певні функції виконувального шару (такі як віртуальна машина, попередня компіляція тощо), клієнти, що обробляють історичні блоки, все ще повинні зберігати відповідний код. Але нові клієнти, ZK-EVM або формальні доведення можуть повністю ігнорувати помаранчеву зону.
Новий жовтий сектор: дуже цінний для розуміння поточного ланцюга або оптимізації побудови блоків, але не належить до логіки консенсусу. Наприклад, Etherscan і деякі будівельники блоків підтримують операції користувачів ERC-4337. Якщо ми замінимо деякі функції Ethereum (такі як EOA і підтримувані ним старі типи транзакцій) реалізацією RISC-V в ланцюзі, код консенсусу значно спроститься, але спеціалізовані вузли можуть продовжувати використовувати оригінальний код для аналізу.
Складність оранжевої та жовтої зон є упаковкою складності, і ті, хто розуміє протокол, можуть пропустити ці частини, Ethereum може їх ігнорувати, помилки в цих зонах не спричинять ризику консенсусу. Тому, кодова складність оранжевої та жовтої зон значно менш небезпечна, ніж складність зеленої зони.
Переміщення коду з зеленої області в жовту область нагадує стратегію Apple забезпечити довгострокову зворотну сумісність через шар перекладу Rosetta.
Натхнений недавньою статтею команди Ipsilon, я пропоную наступний процес змін віртуальної машини (на прикладі EVM до RISC-V, але також може бути використаний для EVM до Cairo або RISC-V до більш оптимальної віртуальної машини):
Вимагати нову попередньо скомпільовану версію, яка надає реалізацію RISC-V в ланцюзі: дати можливість екосистемі поступово адаптуватися до віртуальної машини RISC-V.
Введення RISC-V як варіанту для розробників: протокол підтримує як RISC-V, так і EVM, контракти обох віртуальних машин можуть вільно взаємодіяти.
Замінити більшість попередньо скомпільованих: окрім операцій з еліптичними кривими та KECCAK (через необхідність екстремальної швидкості), реалізувати заміну інших попередньо скомпільованих за допомогою RISC-V. Видалити попередньо скомпільовані через жорсткий форк, одночасно змінивши код цієї адреси (аналогічно форку DAO) з порожнього на реалізацію RISC-V. Віртуальна машина RISC-V надзвичайно проста, навіть на цьому етапі вже суттєво спрощує протокол.
Реалізація EVM інтерпретатора в RISC-V: як смарт-контракт на ланцюзі (оскільки ZK-програміст потребує завершення). Після кількох років з моменту початкового випуску існуючі EVM контракти виконуються через цей інтерпретатор.
Після завершення 4-го етапу багато "EVM реалізацій" все ще будуть використовуватися для оптимізації побудови блоків, інструментів для розробників та аналізу ланцюга, але більше не будуть частиною ключових стандартів консенсусу. Консенсус Ethereum буде "рідним" лише для RISC-V.
Спрощення через компоненти спільного протоколу
Третій спосіб зниження загальної складності протоколу (також найчастіше недооцінюваний) полягає в тому, щоб якомога більше ділитися єдиними стандартами в різних частинах стеку протоколів. Різні протоколи, які виконують одну й ту саму функцію в різних сценаріях, зазвичай не приносять ніякої користі, але ця модель все ж часто виникає, в основному через брак комунікації між різними частинами дорожньої карти протоколів. Ось кілька конкретних прикладів спрощення Ethereum через спільні компоненти.
Уніфікований код для видалення
Ми потребуємо кодів корекції та видалення в трьох сценаріях:
Вибірка доступності даних: клієнт перевіряє, чи блок був опублікований.
Швидша P2P трансляція: вузол може приймати блок після отримання n/2 фрагментів, досягаючи балансу між затримкою та надмірністю.
Розподілене історичне зберігання: фрагментація історичних даних Ethereum, кожна група з n/2 фрагментів може відновити інші фрагменти, що знижує ризик втрати окремого фрагмента.
Якщо використовувати один і той же код корекції помилок (незалежно від того, чи це код Ріда-Соломона, випадковий лінійний код тощо) у трьох різних сценаріях, ви отримаєте такі переваги:
Мінімізуйте обсяг коду: зменшіть загальну кількість рядків коду.
Підвищення ефективності: якщо вузол завантажує частину фрагментів для певного сценарію, ці дані можуть бути використані для інших сценаріїв.
Забезпечте перевірність: усі фрагменти сцен можна перевірити відповідно до кореня.
Якщо використовуються різні коди корекції помилок, принаймні, слід забезпечити їхню сумісність, наприклад, код Ріда-Соломона для вибірки доступності даних на горизонтальному рівні та вертикальний випадковий лінійний код, що працюють в одній області.
Уніфікований формат серіалізації
Серіалізований формат Ethereum наразі лише частково зафіксований, оскільки дані можуть бути повторно серіалізовані та передані в будь-якому форматі. Винятком є хеш підпису транзакції, який повинен бути зафіксований у стандартному форматі для хешування. У майбутньому ступінь фіксації серіалізованого формату буде подальше підвищена з наступних причин:
Повна абстракція облікового запису (EIP-7701): повний зміст транзакції видимий для віртуальної машини.
Вищий ліміт Gas: дані виконавчого рівня повинні бути поміщені в блоки даних (blobs).
Тоді у нас буде можливість уніфікувати три рівні серіалізації Ethereum: рівень виконання, рівень консенсусу, ABI виклику смарт-контракту.
Я пропоную використовувати SSZ, оскільки SSZ:
Легко декодувати: включає в себе в смарт-контракті (оскільки він базується на дизайні з 4 байт і має менше крайніх випадків).
Широко використовується на рівні консенсусу.
Дуже схожий на існуючий ABI: адаптація інструментів відносно проста.
Вже ведуться зусилля щодо повної міграції на SSZ, і ми повинні враховувати та продовжувати ці зусилля при плануванні майбутніх оновлень.
Уніфікована деревоподібна структура
Якщо перейти з EVM на RISC-V (або інші можливі мінімальні віртуальні машини), шістнадцяткове Merkle Patricia дерево стане найбільшим обмеженням для підтвердження виконання блоків, навіть у середньому випадку. Перехід на бінарне дерево, засноване на більш оптимальних хеш-функціях, значно підвищить ефективність доказувача, одночасно зменшуючи витрати на дані в таких сценаріях, як легкі клієнти.
Під час міграції слід забезпечити використання однакової структури дерев у шарі консенсусу. Це дозволить шару консенсусу Ethereum отримувати доступ і аналізувати шар виконання за допомогою одного й того ж коду.
Від тепер до майбутнього
Простота в багатьох аспектах подібна до децентралізації, обидва є верхніми цілями стійкості. Чітке усвідомлення простоти вимагає певної культурної зміни. Її вигоди часто важко кількісно оцінити, тоді як витрати на додаткові зусилля та відмову від деяких вражаючих функцій проявляються негайно. Однак, з часом вигоди будуть ставати дедалі більш помітними — — сам Bitcoin є відмінним прикладом.
Я пропоную наслідувати tinygrad і встановити чітку максимальну цільову кількість рядків коду для довгострокових стандартів Ethereum, щоб ключовий код консенсусу Ethereum наблизився до простоти Bitcoin. Код, що обробляє історичні правила Ethereum, продовжуватиме існувати, але його слід розмістити поза ключовими шляхами консенсусу. Одночасно ми повинні дотримуватися принципу вибору простіших рішень, переважно обираючи інкапсуляцію складності, а не системну складність, і робити вибір дизайну, який забезпечує чіткі атрибути та гарантії.