Автор: protolambda, дослідник OP Labs; укладач: Frank, Foresight News
Щоб створити найпотужнішу та безпечну взаємодіючу мережу рівня 2, Optimism Collective проводить децентралізацію різними шляхами.
Майбутня безвідмовна система OP Stack стане важливим кроком до технологічної децентралізації.Відкритий вихідний код і модульний дизайн OP Stack створюють безпрецедентний етап для соціальної децентралізації екосистеми L2.
У цій статті ми досліджуємо принцип соціальної децентралізації, як архітектура L2 дозволяє Layer 2 розширити цей принцип, щоб включити різноманітність атестації та різноманітність клієнтів, і описуємо, як Optimism Collective використовує цю архітектуру для створення своєї відмовостійкої системи.
"Соціальна децентралізація" На основі Ethereum
Протокол Ethereum отримує переваги від соціальної децентралізації, зокрема, надаючи опціональні рішення, які дозволяють широкому колу учасників брати участь у створенні надійної децентралізованої мережі.
Для вузлового програмного забезпечення це означає різноманіття клієнтів: чим більше у вас клієнтів, тим менший вплив на мережу валідатора має одна точка відмови.
Основні розробники Layer1 описують цю модель внесків як «базар», який є галасливим і здається хаотичним, але дуже ефективним і динамічним. Приймаючи радикально відкритий підхід до розробки протоколу, найширше коло учасників може брати участь і вдосконалювати протокол.
Optimism Collective має унікальні можливості для реалізації та ітерації підходу Ethereum до соціальної децентралізації: OP Stack досягає соціальної децентралізації, надаючи відкриті специфікації та програмне забезпечення з відкритим кодом за ліцензією MIT, а Optimism Collective може досягти соціальної децентралізації, створюючи над ним ітерації суперланцюга.
Більш детальне розуміння архітектури L2
Ethereum має відкриту специфікацію на рівні L1 і модульну клієнтську архітектуру, яка розділяє рівень консенсусу та рівень виконання.
OP-Stack реалізує ту саму архітектуру на L2:
Рівень консенсусу підтримується оп-вузлом і Magi, двома клієнтами, які стежать за L1 і експортують вхідні дані виконання;
Рівень виконання підтримується op-geth, op-erigon і op-reth;
Однак архітектура L2 додає до цього стеку новий рівень: рівень перевірки.
Це рівень, який надійно з’єднує вихідні дані L2 із L1. Подібно до того, як наявність кількох клієнтів є найкращою практикою для забезпечення консенсусу та виконання як на L1, так і на L2, для рівня перевірки L2 наявність кількох методів атестації може забезпечити оптимальну безпеку.
Подібно до валідаторів з різними клієнтами, які досягають консенсусу, кворум атестацій у ланцюжку може показати, що претензії щодо стану L2 були перевірені різними способами, що значно зменшує ймовірність помилок, що призводять до повної відмови.
Наразі існує три поширених типи доказів: атестації, докази помилок (також відомі як докази шахрайства) і докази дійсності з нульовим знанням. Останні два мають загальний шаблон, оскільки вони виражають переходи стану L2 у синхронній формі та доводять їх виконання з урахуванням даних L1 і попереднього стану L2 як вхідних даних.
Ізолюйте компоненти системи перевірки, щоб досягти різноманітності перевірки
Покажіть, що систему можна далі розкласти на незалежні компоненти:
«Програма», яка визначає синхронні переходи стану L2;
«Віртуальна машина» (VM) для запуску та перевірки програми;
«Оракул попереднього зображення», який приймає дані L1 і попередній стан L2 як вхідні дані;
Багато з сучасних підтверджень із нульовим знанням досі тісно поєднують ці компоненти, створюючи ZK-EVM, який працює на одній транзакції L1. Однак стек OP відокремлює їх, щоб ізолювати складність і забезпечити різноманітність клієнтів, роблячи ціле більш потужним.
Інтерактивні докази помилок додають ігри з розділенням навпіл до трасування віртуальної машини, щоб перевірити докази в ланцюжку, тоді як докази з нульовим знанням на основі віртуальної машини перевіряють арифметику та згортають виконання та забезпечують докази дійсності. (Дивіться докази нульового знання на основі віртуальної машини, які Risc0 та O(1)-Labs розробляють у відповідь на запити про пропозиції Optimism ZK).
Програма визначає фактичний перехід стану як "клієнт", а вхідні дані (дані L1 і попередній стан L2) як "сервер". Програма працює незалежно від сервера/клієнта без віртуальної машини, схоже на звичайний блокчейн-вузол, і використовує багато коду.
Наприклад, клієнт оп-програми Go створюється шляхом імпорту форка оп-вузла та EVM з op-geth, тоді як сервер отримує дані з L1 і L2 Ethereum RPC.
Функціональний огляд FPVM
Захищена від збоїв віртуальна машина (FPVM) — один із модулів захищеного від збоїв стеку в OP Stack.
Ця віртуальна машина не реалізує нічого специфічного для Ethereum або L2, окрім надання правильних інтерфейсів (особливо тих, що пов’язані з оракулами попереднього зображення).Клієнт програми перевірки помилок (FPP), що працює в FPVM, має виражати частину перетворення стану L2.
Завдяки цьому розділенню віртуальна машина залишається мінімальною: зміни в протоколі Ethereum (наприклад, додавання кодів операцій EVM) не впливають на віртуальну машину.
Натомість, коли протокол змінюється, FPP можна просто оновити, щоб імпортувати нові компоненти переходу стану в програмне забезпечення вузла.Подібно до гри в нову версію гри на тій самій ігровій консолі, систему атестації L1 можна оновити, щоб підтвердити різні програми.
Віртуальна машина відповідає за виконання низькорівневих інструкцій і потребує імітації FPP. Вимоги до віртуальної машини нижчі: програми виконуються синхронно, а всі вхідні дані завантажуються через той самий оракул попереднього образу, але все це ще потрібно підтвердити в ланцюжку L1 EVM.
Щоб зробити це, одночасно можна перевірити лише одну інструкцію. Гра з поділенням скоротить завдання доведення повних слідів виконання лише до однієї інструкції.
Доказ інструкції може виглядати по-різному для кожного FPVM, але зазвичай виглядає схожим на Cannon, який підтверджує інструкцію наступним чином:
Щоб виконати цю інструкцію, віртуальна машина моделює щось подібне до циклу інструкцій контексту потоку: інструкція зчитується з пам’яті, інтерпретується, і деякі зміни можуть відбуватися у файлі реєстру та пам’яті;
Для підтримки основних потреб виконання програм, таких як оракули попереднього образу та розподіл пам’яті, виконання також підтримує підмножину системних викликів Linux. Системні виклики читання/запису дозволяють взаємодіяти з оракулом попереднього образу: програма записує хеш як запит на отримання попереднього образу, а потім читає його порціями за раз;
Cannon, перша FPVM, реалізувала віртуальну машину MIPS таким чином. Щоб отримати додаткові відомості про віртуальні машини, перегляньте відповідну документацію та специфікації гармати. Інтерфейс між програмами FPVM і FP стандартизований і задокументований у специфікаціях.
Від FPVM до ZKVM
Докази помилок — не єдиний тип доказів переходу стану, докази валідності ZK є привабливим варіантом через їхній потенціал для швидкого міжланцюжкового перемикання (оскільки докази валідності ZK не мають викликів у ланцюжку, немає вікна суперечок). Щоб підтримувати розширений стек Ethereum і розміщувати різні клієнтські реалізації, нам все одно потрібно від’єднати віртуальну машину від програми.
Це підхід, використаний проектом ZK RFP, щоб довести, що мінімальна віртуальна машина RISC-V (від Risc0) або MIPS (від O(1) Labs) може розміщувати ту саму програму, яка використовується в доказі помилки.
Підтримка ZK-VM справді потребує деяких незначних налаштувань, щоб дозволити оракулам-попередникам завантажувати дані неінтерактивно, але завдяки узагальненню віртуальної машини ZK виявляється більш перспективним у майбутньому перед обличчям змін OP Stack.
Можливості для зовнішніх учасників
OP Stack підтримує додаткові параметри віртуальної машини та програми, а також додаткові незалежні системи доказів, від доказів до доказів із нульовим знанням. Так само, як різноманітність клієнтів, різноманітність доказів є результатом колективних зусиль.
Доповнення до рівня перевірки OP Stack, які зараз виконуються, включають:
RISC-V FPVM "Asterisc", розроблений protolambda та написаний мовою Go;
Програма Rust FP на основі Magi та op-reth, створена учасниками Base та OP Labs;
Програма Rust ZK на основі zeth (гілка ZK-reth), створена Risc0;
У міру того, як гармата, операційна програма, гра навпіл і безмежна креативність спільноти з відкритим кодом розвиваються, з’явиться багато додаткових можливостей зробити внесок у стек через впровадження тестів і участь у програмах винагород за помилки.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Інтерпретація відмовостійкої системи, яка буде запущена OP Stack: великий крок до децентралізації
Автор: protolambda, дослідник OP Labs; укладач: Frank, Foresight News
Щоб створити найпотужнішу та безпечну взаємодіючу мережу рівня 2, Optimism Collective проводить децентралізацію різними шляхами.
Майбутня безвідмовна система OP Stack стане важливим кроком до технологічної децентралізації.Відкритий вихідний код і модульний дизайн OP Stack створюють безпрецедентний етап для соціальної децентралізації екосистеми L2.
У цій статті ми досліджуємо принцип соціальної децентралізації, як архітектура L2 дозволяє Layer 2 розширити цей принцип, щоб включити різноманітність атестації та різноманітність клієнтів, і описуємо, як Optimism Collective використовує цю архітектуру для створення своєї відмовостійкої системи.
"Соціальна децентралізація" На основі Ethereum
Протокол Ethereum отримує переваги від соціальної децентралізації, зокрема, надаючи опціональні рішення, які дозволяють широкому колу учасників брати участь у створенні надійної децентралізованої мережі.
Для вузлового програмного забезпечення це означає різноманіття клієнтів: чим більше у вас клієнтів, тим менший вплив на мережу валідатора має одна точка відмови.
Основні розробники Layer1 описують цю модель внесків як «базар», який є галасливим і здається хаотичним, але дуже ефективним і динамічним. Приймаючи радикально відкритий підхід до розробки протоколу, найширше коло учасників може брати участь і вдосконалювати протокол.
Optimism Collective має унікальні можливості для реалізації та ітерації підходу Ethereum до соціальної децентралізації: OP Stack досягає соціальної децентралізації, надаючи відкриті специфікації та програмне забезпечення з відкритим кодом за ліцензією MIT, а Optimism Collective може досягти соціальної децентралізації, створюючи над ним ітерації суперланцюга.
Більш детальне розуміння архітектури L2
Ethereum має відкриту специфікацію на рівні L1 і модульну клієнтську архітектуру, яка розділяє рівень консенсусу та рівень виконання.
OP-Stack реалізує ту саму архітектуру на L2:
Рівень консенсусу підтримується оп-вузлом і Magi, двома клієнтами, які стежать за L1 і експортують вхідні дані виконання;
Рівень виконання підтримується op-geth, op-erigon і op-reth;
Однак архітектура L2 додає до цього стеку новий рівень: рівень перевірки.
Це рівень, який надійно з’єднує вихідні дані L2 із L1. Подібно до того, як наявність кількох клієнтів є найкращою практикою для забезпечення консенсусу та виконання як на L1, так і на L2, для рівня перевірки L2 наявність кількох методів атестації може забезпечити оптимальну безпеку.
Подібно до валідаторів з різними клієнтами, які досягають консенсусу, кворум атестацій у ланцюжку може показати, що претензії щодо стану L2 були перевірені різними способами, що значно зменшує ймовірність помилок, що призводять до повної відмови.
Наразі існує три поширених типи доказів: атестації, докази помилок (також відомі як докази шахрайства) і докази дійсності з нульовим знанням. Останні два мають загальний шаблон, оскільки вони виражають переходи стану L2 у синхронній формі та доводять їх виконання з урахуванням даних L1 і попереднього стану L2 як вхідних даних.
Ізолюйте компоненти системи перевірки, щоб досягти різноманітності перевірки
Покажіть, що систему можна далі розкласти на незалежні компоненти:
Багато з сучасних підтверджень із нульовим знанням досі тісно поєднують ці компоненти, створюючи ZK-EVM, який працює на одній транзакції L1. Однак стек OP відокремлює їх, щоб ізолювати складність і забезпечити різноманітність клієнтів, роблячи ціле більш потужним.
Інтерактивні докази помилок додають ігри з розділенням навпіл до трасування віртуальної машини, щоб перевірити докази в ланцюжку, тоді як докази з нульовим знанням на основі віртуальної машини перевіряють арифметику та згортають виконання та забезпечують докази дійсності. (Дивіться докази нульового знання на основі віртуальної машини, які Risc0 та O(1)-Labs розробляють у відповідь на запити про пропозиції Optimism ZK).
Програма визначає фактичний перехід стану як "клієнт", а вхідні дані (дані L1 і попередній стан L2) як "сервер". Програма працює незалежно від сервера/клієнта без віртуальної машини, схоже на звичайний блокчейн-вузол, і використовує багато коду.
Наприклад, клієнт оп-програми Go створюється шляхом імпорту форка оп-вузла та EVM з op-geth, тоді як сервер отримує дані з L1 і L2 Ethereum RPC.
Функціональний огляд FPVM
Захищена від збоїв віртуальна машина (FPVM) — один із модулів захищеного від збоїв стеку в OP Stack.
Ця віртуальна машина не реалізує нічого специфічного для Ethereum або L2, окрім надання правильних інтерфейсів (особливо тих, що пов’язані з оракулами попереднього зображення).Клієнт програми перевірки помилок (FPP), що працює в FPVM, має виражати частину перетворення стану L2.
Завдяки цьому розділенню віртуальна машина залишається мінімальною: зміни в протоколі Ethereum (наприклад, додавання кодів операцій EVM) не впливають на віртуальну машину.
Натомість, коли протокол змінюється, FPP можна просто оновити, щоб імпортувати нові компоненти переходу стану в програмне забезпечення вузла.Подібно до гри в нову версію гри на тій самій ігровій консолі, систему атестації L1 можна оновити, щоб підтвердити різні програми.
Віртуальна машина відповідає за виконання низькорівневих інструкцій і потребує імітації FPP. Вимоги до віртуальної машини нижчі: програми виконуються синхронно, а всі вхідні дані завантажуються через той самий оракул попереднього образу, але все це ще потрібно підтвердити в ланцюжку L1 EVM.
Щоб зробити це, одночасно можна перевірити лише одну інструкцію. Гра з поділенням скоротить завдання доведення повних слідів виконання лише до однієї інструкції.
Доказ інструкції може виглядати по-різному для кожного FPVM, але зазвичай виглядає схожим на Cannon, який підтверджує інструкцію наступним чином:
Cannon, перша FPVM, реалізувала віртуальну машину MIPS таким чином. Щоб отримати додаткові відомості про віртуальні машини, перегляньте відповідну документацію та специфікації гармати. Інтерфейс між програмами FPVM і FP стандартизований і задокументований у специфікаціях.
Від FPVM до ZKVM
Докази помилок — не єдиний тип доказів переходу стану, докази валідності ZK є привабливим варіантом через їхній потенціал для швидкого міжланцюжкового перемикання (оскільки докази валідності ZK не мають викликів у ланцюжку, немає вікна суперечок). Щоб підтримувати розширений стек Ethereum і розміщувати різні клієнтські реалізації, нам все одно потрібно від’єднати віртуальну машину від програми.
Це підхід, використаний проектом ZK RFP, щоб довести, що мінімальна віртуальна машина RISC-V (від Risc0) або MIPS (від O(1) Labs) може розміщувати ту саму програму, яка використовується в доказі помилки.
Підтримка ZK-VM справді потребує деяких незначних налаштувань, щоб дозволити оракулам-попередникам завантажувати дані неінтерактивно, але завдяки узагальненню віртуальної машини ZK виявляється більш перспективним у майбутньому перед обличчям змін OP Stack.
Можливості для зовнішніх учасників
OP Stack підтримує додаткові параметри віртуальної машини та програми, а також додаткові незалежні системи доказів, від доказів до доказів із нульовим знанням. Так само, як різноманітність клієнтів, різноманітність доказів є результатом колективних зусиль.
Доповнення до рівня перевірки OP Stack, які зараз виконуються, включають:
У міру того, як гармата, операційна програма, гра навпіл і безмежна креативність спільноти з відкритим кодом розвиваються, з’явиться багато додаткових можливостей зробити внесок у стек через впровадження тестів і участь у програмах винагород за помилки.