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