Особлива подяка Fede, Danno Ferrin, Justin Drake, Ladislaus та Tim Beiko за їх відгуки та рецензії.

Метою Ethereum є стати глобальним реєстром - платформою, яка несе людські активи та записи, що є базовим шаром для застосувань, таких як фінанси, управління та верифікація даних високої вартості. Для досягнення цієї мети вона повинна мати як масштабованість, так і стійкість. План хардфорку Fusaka збільшить простір доступності даних L2 в 10 разів, тоді якЗапропонована дорожня карта на 2026 рікТакож включає подібний масштаб розширення даних рівня L1. Тим часом, 'The Merge' оновив Ethereum до механізму консенсусу доказів уламку (PoS).Різноманіття клієнтів швидко зростає, ZK (Zero-Knowledge Proof) підтверджуваність та стійкість до квантових атак також поступово розвиваються, а екосистема застосувань зростаєДорослий і міцний.

Метою цієї статті є підкреслити рівно важливий, але часто недооціненийСтійкість (і врешті-решт масштабованість)Елементи:
Простота протоколу.

Одним із найбільш високо оцінюваних аспектів Bitcoin є його дизайн протоколу, який є дуже елегантним і простим:

Система - це блокчейн, що складається з серії блоків. Кожен блок пов'язаний з попереднім через хеш. Дійсність кожного блоку перевіряється за допомогою доказу роботи (PoW), що означає... вам просто потрібно перевірити, чи ведучі цифри його хешу - це нулі. Кожен блок містить транзакції, які витрачають монети, отримані в результаті майнінгу, або витрачають монети, отримані з попередніх транзакцій. В цьому все.
Навіть розумний старшокласник має здатність повністю розуміти принципи роботи протоколу Bitcoin. І програміст може навіть розробити клієнт Bitcoin як хобі проект.

Збереження протоколу простим приносить цілий ряд ключових переваг, що потенційно робить Bitcoin та EthereumДовірена нейтральністьОсновний рівень глобальної довіри:

• Зробіть логіку протоколу легше зрозуміти, розширте групу, яка може брати участь у дослідженнях, розробці та управлінні протоколом, знизьте технічні бар'єри та уникайте домінування 'технологічного бюрократичного класу' у протоколі.
• Значно зменшити витрати на розробку нової інфраструктури, що інтегрується з протоколами (такими як нові клієнти, нові перевіряючі, нові інструменти для журналювання тощо).
• Зменшити витрати на довгострокове обслуговування протоколу.
• Зменшення ризику катастрофічних вразливостей, чи то в специфікаціях протоколу, чи в коді реалізації; це також упрощує перевірку того, що протокол не містить такі вразливості.
• Зменшити соціальну атакувальну поверхню: чим менше компонентів, тим менше місць, які можуть бути використані та контрольовані конкретними зацікавленими сторонами.

У минулому Ethereum не добре справлявся з цим (іноді навіть через мої особисті рішення), що призвело до наших занадто великих розходів на розвиток,@vbuterin/саморуй>Різноманітні безпечність ризики та закритий характер культури досліджень та розробок, і ці зусилля часто приносять лише ілюзорні результати.
Ця стаття пояснить, як Ефіріум може досягти рівня простоти, близького до Біткойна, за п'ять років.

Спрощений Шар Згоди

3-слотова фінальність (3-слотова фінальність) схема — 3sf-mini

Новий дизайн шару консенсусу (раніше відомий як 'ланцюжок променів') спрямований на інтеграцію досвіду, який ми накопичили в теорії консенсусу, розробці ZK-SNARK, економіці стейкінгу та інших областях протягом останнього десятиліття, для створення довгострокового оптимального шару консенсусу Ethereum. Цей новий шар консенсусу, в порівнянні з існуючим Ланцюжком маяка, очікується, що досягне вищої простоти. Це особливо виразно в:

• 3-слотова реструктуризація фінальності
  Цей дизайн усуває відмінність між 'слотом' та 'епохою', перетасовку комітету та інші деталі специфікації протоколу, пов'язані з цими механізмами (наприклад, синхронні комітети). Базова версія 3-слотової остаточності,Треба лише близько 200 рядків кодуЦе можливо. Порівняно з поточним протоколом Gasper, 3-слотова остаточність також має близьку до оптимальної безпеку.
• Кількість активних перевіряючих зменшилася
  Робить його безпечнішим та більш реалізовним для прийняття простішого правила вибору відгалуження.
• Протокол агрегації на основі STARK
  Означає, що кожен може стати агрегатором, не турбуючись про довіру до агрегатора, занадто високі комісії за повторні бітові поля і т. Д. Хоча сама агрегаційна шифрування має певну складність, цеВисокоінкапсульована складністьЗагальний системний ризик протоколу набагато нижчий.
• Два вищезазначених пункти також ймовірно підтримують простішу та надійнішу архітектуру однорангових (p2p) мереж.
• У нас є можливість переосмислити механізми входу, виходу, виведення, перемикання ключа, покарання за інерцію тощо валідатора та спростити їх - не лише зменшуючи кількість рядків коду (LoC), але й надаючи більш ясні гарантії механізму, такі як більш явний термін «слабкої суб'єктивності».

Перевага рівня консенсусу полягає в тому, що він відносно відокремлений від виконання EVM, тому у нас є багато місця для продовження розвитку цих покращень.
Більш складно: як досягти такого ж спрощення на рівні виконання.

Спрощений Шар Виконання

Складність віртуальної машини Ethereum (EVM) постійно зростає, і багато цієї складності було доведено зайвим (часто також пов'язано з моїми особистими рішеннями): у нас є 256-бітна віртуальна машина, яка занадто оптимізована для дуже конкретних криптографічних форм, які поступово виходять з ужитку; а деякі попередньо скомпільовані контракти занадто фокусуються на дуже небагатьох випадках використання.

Спроба поступово виправити ці практичні проблеми не є можливою.Видалити @vbuterinІнструкція SELFDESTRUCT використовує велику кількість енергії, проте результати обмежені. Недавня дискусія про EOF (EVM Object Format) додатково демонструє складність внесення подібних змін до віртуальної машини.

Отже, як альтернативу, я нещодавно запропонував більш радикальну ідею: замість здійснення інкрементальних (але все ще руйнівних) змін для покращення у 1,5 рази, краще безпосередньо перейти до зовсім нової, набагато кращої та простішої віртуальної машини з метою отримання виграшу в 100 разів. Точно так само, як і «Злиття», ми зменшуємо кількість перетворень, але кожне з них є значущим. Конкретно, я пропоную замінити існуючу EVM на RISC-V (або іншу віртуальну машину, яку буде використовувати доведник ZK Ethereum). Таким чином, ми досягнемо:

• Значне покращення ефективності: оскільки розумні контракти можуть виконуватися безпосередньо в перевірці без накладних витрат на інтерпретатор. Лаконічні дані показують, що продуктивність може бути покращена більш ніж у 100 разів в багатьох сценаріях.
• Найпростіша простота: порівняно з EVM, специфікація RISC-VДуже просто. Інші альтернативні рішення (такі як Каїр) є так само лаконічними.
• Наслідуючи очікувані переваги EOF: такі як сегментація коду, більш дружня статичний аналіз, більший обмеження щодо обсягу коду тощо.
• Розробники мають більше вибору: Solidity та Vyper можуть бути скомпільовані до нового віртуального машинного фонду. Якщо вибраний RISC-V, розробники мов можуть також легко портувати свій код.
• Значно зменшити потребу у попередньому компілюванні: можливо залишивши лише кілька високооптимізованих операцій на еліптичній кривій (хоча вони більше не існуватимуть, коли квантові обчислення стануть популярними).

Основним недоліком цього підходу є те, що, на відміну від EOF (негайно використовуваний), нова віртуальна машина потребує більше часу, щоб стати корисною для розробників. Для пом'якшення цього, ми можемо ввести деякі невеликі, але високоцінні покращення EVM в найближчий час.Збільшити обмеження розміру коду контрактуЗбільшити інструкції DUP/SWAP17-32 та інше.)

У кінцевому підсумку це дозволить нам отримати значно спрощену віртуальну машину. Але найбільше питання: що ж робити з існуючим EVM?

Стратегія сумісності зі зворотною сумісністю VM

При наданні змістовного спрощення (або навіть лише покращення без додавання складності) будь-якої частини віртуальної машини Ethereum (EVM) найбільшою виклик є: як забезпечити зворотню сумісність з існуючими програмами при досягненні поставленої мети.

По-перше, слід зрозуміти, що не існує єдиного способу визначити обсяг “кодової бази Ethereum” (навіть у межах одного клієнта).

Мета полягає в мінімізації обсягу зеленої зони настільки, наскільки це можливо: тобто логіка, яку вузли повинні виконувати для участі в консенсусі Ethereum, включаючи обчислення поточного стану, доказ, валідацію, FOCIL (перший рівень цілісності консенсусу), побудову основного блоку тощо.

Помаранчеву область не можна зменшити: якщо певна функція рівня виконання (чи то віртуальна машина, попереднє компілювання або інший механізм) видаляється зі специфікації протоколу або її функціональність змінюється, клієнт, який займається обробкою історичних блоків, все ще повинен зберігати її - але важливо, нові клієнти (такі як ZK-EVM або формальні перевіряючі) можуть ігнорувати помаранчеву область повністю.

Нова категорія - жовта зона: цей тип коду є дуже важливим для розуміння та аналізу поточного стану ланцюга та для побудови найкращих блоків, але він не є частиною консенсусу. Приклад - Etherscan(І деякіБлок-будівник) Підтримка операцій користувача ERC-4337. Якщо ми використовуємо реалізацію RISC-V на ланцюжку для заміни певних великих функцій Ethereum (таких як рахунки EOA та їх підтримка різних старих типів транзакцій), то, незважаючи на значне спрощення коду консенсусу, деякі професійні вузли можуть продовжувати використовувати оригінальний код для розбору цих функцій.

Важливо, що помаранчева та жовта зони належать "Gate"Складність інкапсуляціїКожен, хто бажає зрозуміти протокол, може їх пропустити, клієнти Ethereum також можуть вибрати не реалізовувати їх, і помилки в цих областях не будуть становити ризику для консенсусу. Це означає, що складність коду та негативний вплив, які приносять оранжева та жовта області, набагато менше, ніж зелена область.

Перемістіть код з зеленої зони в жовту зону, цей підхід схожий на Apple Inc.Перекладайте через шар РозеттиДля забезпечення довгострокової сумісності.

Я запропонував (позичено з@ipsilon/eof-ethereums-gateway-to-risc-v”> Недавні погляди команди Ipsilon) Процес міграції віртуальної машини (використання міграції EVM на RISC-V як прикладу, але також застосовний для міграції EVM в Cairo, і навіть майбутньої міграції до більш оптимальної віртуальної машини):

1. Усі нові попередні компіляції повинні бути написані в стандартній реалізації RISC-V на ланцюгу, щоб екосистема могла почати ознайомлюватися з та використовувати RISC-V як віртуальну машину.
2. Представляючи RISC-V як варіант для розробки контрактів паралельно з EVM для розробників. Протокол нативно підтримує як RISC-V, так і EVM, дозволяючи контрактам, написаним обома мовами, взаємодіяти вільно.
3. Замінити всі попередні компіляції (крім операцій з еліптичними кривими та KECCAK) на реалізацію RISC-V. Ми видаляємо ці попередні компіляції через хардфорк і в той же час змінюємо код за відповідною адресою (у стилі хардфорка DAO) на реалізацію RISC-V. Оскільки RISC-V VM надзвичайно лаконічний, навіть просто це спрощує загальну структуру.
4. Реалізувати інтерпретатор EVM, написаний на RISC-V, та розгорнути його як смарт-контракт на ланцюжку. Після кількох років початкового релізу існуючі EVM-контракти будуть оброблятися через цей інтерпретатор.

Після завершення кроку 4 буде все ще використовуватися багато 'реалізацій EVM' для оптимізації конструкції блоку, засобів розробки та аналізу on-chain, але вони більше не будуть частиною ключових специфікацій узгодження. Тоді узгодження Ethereum буде 'по-суті' розуміти лише RISC-V.

Спростити шляхом спільної використання протокольних компонентів

Третій, і, можливо, найбільш недооцінений, метод спрощення - це поділ єдиного стандарту між різними частинами стеку протоколу якомога більше. Зазвичай немає причин використовувати різні протоколи для однієї й тієї ж мети в різних сценаріях, але ця ситуація все ще часто відбувається на практиці, головним чином через відсутність комунікації між різними частинами дорожньої карти протоколу. Ось деякі конкретні приклади спрощення Ethereum через «максимізацію спільного використання компонентів»:

Уніфікований код стирання

Нам потрібно виправити код видалення у трьох сценаріях:

• Вибіркова перевірка доступності даних - Клієнт перевіряє, чи був опублікований блок
• Швидша трансляція P2P - Вузли можуть приймати блоки після отримання n/2 з n блоків, тим самим встановлюючи оптимальний баланс між зменшенням затримки та зайвістю.
• Розподілене зберігання історії - Кожен шматок історії Ethereum зберігається в багатьох блоках, тому (i) ці блоки можуть бути незалежно перевірені, і (ii) половина блоків в кожній групі може відновити решту, значно зменшуючи ризик втрати будь-якого окремого блоку.

Якщо ми використовуємо той самий код стирання (чи то Рід-Соломона, випадковий лінійний код чи інший) в трьох випадках використання, ми отримаємо деякі важливі переваги:

1. Мінімізувати загальну кількість рядків коду
2. Покращити ефективність, оскільки кожен вузол повинен завантажувати різні частини блоку для одного випадку використання (замість цілого блоку), дані можуть бути використані для іншого випадку використання
3. Забезпечте перевірку: Всі три блоки в контексті можна перевірити на основі кореня

Якщо дійсно потрібні різні коди коригування помилок, 'сумісність' має бути забезпечена, принаймні: наприклад, в сценарії DAS горизонтально використовується код Ріда-Соломона, а вертикально - випадковий лінійний код, але обидва базуються на одному математичному полі.

Уніфікований формат серіалізації

На даний момент формат серіалізації Ethereum, строго кажучи, лише "півстандартизований", оскільки дані можуть бути повторно серіалізовані та розіслані у будь-якому форматі. Єдиним винятком є хеш підпису транзакції, де потрібний стандартизований формат для обчислення хешу.
Але стандартизація майбутніх форматів серіалізації буде подальш вдосконалена з двох причин:

• Комплексна абстракція облікового запису (EIP-7701): Віртуальна машина зможе бачити повний зміст транзакції
• Збільшення газового ліміту: Виконання даних блоку потрібно упакувати в блоб

У той час ми матимемо можливість уніфікувати рішення з серіалізації, необхідні для поточних трьох аспектів: 1) шар виконання; 2) шар згоди; 3) виклик інтелектуального контракту ABI.

Я пропоную прийнятиSSZ(Проста серіалізація), оскільки SSZ має наступні переваги:

• Легко розшифрувати: включаючи всередині смарт-контрактів (на основі 4-байтового дизайну, декілька крайових випадків)
• Широко використовується в консенсусі
• Високо схожий з наявним ABI: низькі витрати на міграцію інструментів

На даний момент було додано більше компонентівМіграціяДо SSZРоботаПлануючи майбутні оновлення, ми повинні повністю розглянути та використовувати ці досягнення.

Єдина структура дерева

Після переходу від EVM до RISC-V (або іншої мінімалістичної VM), шістнадцяткове дерево Merkle Patricia стане найбільшим обмеженням для підтвердження виконання блоку, навіть в середніх сценаріях. Перехід до функції хешуванняБінарне дерево, значно покращить ефективність верифікатора та зменшить витрати даних для легких вузлів та інших сценаріїв.

Під час завершення міграції деревовидної структури слід також забезпечити, щоб шар консенсусу використовував ту саму деревовидну структуру, щоб забезпечити можливість доступу та розбору всього Ethereum - як шару консенсусу, так і виконавчого шару - за допомогою одного набору коду.

Відтепер до майбутнього

Спрощення та децентралізація мають багато спільних рис. Обидва є вимогами верхнього рівня, необхідними для досягнення вищої мети стійкості системи. Націлюючи спрощення явно, потрібен культурний зміщення. Переваги спрощення часто важко помітити на початкових етапах, але витрати можливості та додаткове навантаження від відмови від цих «блискучих нових функцій» негайно очевидні. Однак з часом довгострокова цінність спрощення стає все більш очевидною - сам по собі Bitcoin є відмінним прикладом.

Я пропоную, щоб миВчіться з підходу tinygradДля встановлення чіткої мети обмеження кодової лінії для довгострокової специфікації Ethereum метою є зробити критичний код консенсусу Ethereum якомога ближче до мінімалістичного стилю Bitcoin. Код, який працює з історичними правилами Ethereum, все ще існуватиме, але повинен бути ізольований від критичного шляху консенсусу. В той же час ми повинні сформувати універсальний принцип дизайну: обирати простіші рішення, коли це можливо, надавати пріоритет вкладеній складності над системною складністю та нахилятися до дизайнерських рішень, які надають чіткі перевірені властивості та гарантії.

Відмова від відповідальності:

1. Ця стаття є перепублікованою з [vitalik]. Усі авторські права належать оригінальному автору [vitalikУвесь. Якщо у вас є заперечення щодо цього передруку, будь ласка, звертайтесяGate LearnКоманда вчасно займеться цим.
2. Попередження: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Команда Gate Learn перекладає статті на інші мови. Копіювання, поширення або плагіат перекладених статей заборонені, якщо не вказано інше.