переслати оригінальний заголовок «ми всі будуємо одну й ту ж річ»

вступ

цей пост аналізує наступне

• асинхронне виконання - чому високопродуктивні інтегровані блокчейни (наприклад,СоланаіМонадаВідділить виконання від узгодження порядку (послідовності).
• лінива послідовність - як вони будуть відтворювати дизайн лінивого послідовника (наприклад,@astriaorg/hj6ccpp9t">astria).
• передпідтвердження - передпідтвердження на ethereum l1 та на основі rollups.
• на основі проти не на основі - порівняння на основі роллапів + попередніх конфігурацій проти роллапів без основи + відновлення базового рівня.
• універсальна синхронна компонованість - через атомне включення (зі спільними послідовниками) + криптографічна безпека (наприклад,AggLayerі / або в реальному часі доказуючи).
• швидкі ролапи на основі - ролапи на основі повинні мати швидкий базовий шар.
• ігри на час - Час - це гроші, і як це лежить в основі відмінних кінцевих ігор між solana і ethereum.
• децентралізація для опору цензурі - як розрив між підтверджувачем та пропонувачемчерезаукціони виконанняможе зберігати децентралізованих валідаторів, які можуть забезпечити опір цензурісписки включення.

наостанок, і найважливіше, ми побачимо чомуми всі будуємо одну і ту саму прокляту річтак може, ми просто…

оптимізація реплікації станової машини (smr)

ми розглянемо основи, щоб побачити, що кінцева гра для високопродуктивних блокчейнів (наприклад,Солана, Монада, @patrickogradyстратегія пом'якшення - забезпечити максимізацію прибутку будівельників для мінімізації недійсних tps">hypersdk) наближається долінивий послідовник (наприклад, @astriaorg/hj6ccpp9t">astria). ми повернемося до порівняння їх з роллапами на основі Ethereum + preconfs.

послідовність проти виконання

блокчейнирепліковані машини стануДецентралізовані вузли кожен мають і оновлюють свій власний екземпляр стану системи. Щоб продовжити ланцюг, вузли виконують функцію переходу стану (stf) над поточним станом + новими вхідними даними (наприклад, нові транзакції). Це призводить до нового стану.

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

• синтаксично валідний - транзакція має правильну структуру та підпис.
• семантично валідний - транзакція виконує дійсний перехід стану (наприклад, оплачує необхідні витрати).
• послідовність - визначення порядку та включення даних.
• виконати - тлумачте і дійте з даними відповідно до stf.
• створити - створити блок (або частковий блок chunk/shred) з операцій, збережених локально.
• перевірити - виконати необхідну синтаксичну та/або семантичну перевірку блоку (або частини блоку / шматка / обривку).
• реплікувати - поширювати блок (або частковий блок чанк / шред) на інші валідатори.

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

Додатково, вузли перевіряють та реплікують дані по всій мережі. Вузли досягають консенсусу, щоб зберегти послідовний вигляд ланцюга.

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

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

традиційний SMR

традиційний smr (наприклад, ethereum) тісно пов'язує послідовність та виконання. Повні вузли постійно послідовно виконують всі транзакції базового рівня - обидва є обов'язковими умовами для того, щоб вузли досягли консенсусу. Крім того, вузли повинні перевірити, що всі дані блоку доступні (і послідовно впорядковані), вони також повинні виконати блок для перевірки того, що:

• всі транзакції синтаксично та семантично правильні
• новий обчислений стан відповідає тому, який надав лідер

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

у цій традиційній моделі будівництво та перевірка обидва включають виконання.

джерело:@patrickogrady/rys8mdl5p# Створення аргументів на користь розподіленого відтворення машини стану (DSMR)">vryx: зміцнення розподіленого відтворення машини стану

стрімінг smr

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

джерело: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: зміцнення реплікації декупльованої машини стану

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

асинхронне виконання

інтегрований підхід

Тепер, чи можемо отримати ще кращу продуктивність, якщо ми розслабимо ці обмеження?

асинхронне виконання вилучає виконання з гарячого шляху згоди - вузли просто приходять до згоди щодо порядку даних без виконання цих даних. це ефективніше, тому що СоланаіMonad Обидва планують впровадити асинхронне виконання.

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

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

це, ймовірно, томуКеон вірить, що в кінцевому підсумку кожен блокчейн використовуватиме асинхронне виконання, і це ключовий елемент Кінцевий візіон Toly для Solana:

«синхронне виконання передбачає, що всі вузли, які голосують і створюють блоки, повинні бути перевантажені для найгіршого випадку часу виконання в будь-якому блоку ... вузли консенсусу можуть виконувати менше роботи перед голосуванням. роботу можна агрегувати та пакувати, що дозволяє ефективно виконувати її без будь-яких промахів кешу. Це навіть може виконуватися на зовсім іншій машині від вузлів консенсусу або лідерів. Користувачі, які прагнуть синхронного виконання, можуть виділити достатньо апаратних ресурсів для виконання кожного переходу стану в реальному часі без очікування решти мережі.

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

варто відзначити, що ми також хочемо, щоб правда легко виявлялася користувачам, і це означає надійну підтримку для легких клієнтів. Деякі з цих проектів, які значно затримують виконання, зроблять це складним (наприклад,Solana розглядає можливість вимагати це тільки один раз на епоху) порівняно з іншими, що надають корені стану з меншою затримкою (наприклад, як у hypersdk).

модульний підхід

роз'єднання послідовності та виконання може звучати дуже знайомо, оскільки це також «модульний» підхід! комбінування різних рівнів, які спеціалізуються на різних завданнях. роз'єднання послідовності та виконання є ключовим принципом проектування ледачих послідовників (наприклад, astria):

• послідовність - вузли послідовника лише досягають згоди щодо порядку та доступності даних rollup (тобто вони упорядковують, але не виконують).
• виконання - вузли rollup виконують свої відповідні дані після того, як послідовник зобов'язався до нього.

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

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

У будь-якому випадку, нам потрібна дійсно велика та швидка труба для замовлення даних:

проте слід зауважити, що технічно ви можете використовувати практично будь-який ланцюг як лінивий послідовник. Це просто велика труба для даних в кінці дня. Rollup може наївно кидати свої довільні дані на свій вибраний базовий рівень (чи це ефіріум, біткоїн, монада тощо), щоб неявно використовувати його як свій послідовник. Вузли rollup можуть асинхронно виконувати дані після факту.

Різниця на практиці полягає в тому, що ланцюжки, які ми насправді називаємо «лінивими секвенсерами», спеціалізовані для цього завдання, що набагато легше сказати, ніж зробити (наприклад, підтримка необхідних типів транзакцій, розкриття простих інтерфейсів, реалізація інфраструктури MEV, швидкий час слотів, надійне включення транзакцій, висока пропускна здатність тощо). В результаті, вузли для інтегрованих ланцюжків в кінцевому підсумку виконують більшу частину даних, які вони включають, в той час як ліниві секвенсери залишають це в першу чергу роллапам.

ось чому це не так просто, як "чому ми просто не йдемо використовувати solana (або будь-який інший ланцюг, коли це ніколи не було ціллю дизайну) як послідовник rollup?" :

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

зміцнення роз'єднаного SMR

Чи можемо ми вирішити ці проблеми, розслабивши ці обмеження? Коротко кажучи, так, наївні реалізації дійсно призводять до проблем, таких як дозвіл недійсних транзакцій, які не можуть сплатити комісію (що становить потенційний вектор DDoS-атак, якщо реалізовано наївно), але їх можна вирішити так, щоб вони не були серйозними проблемами.

ми не будемо вдаватися в деталі тут, але ви можете звертатися доПатрік О'Грейдічудова робота на@patrickogrady/ rys8mdl5p # зміцнення відокремленого SMR, толіасинхронне виконання кінцевої гри, та Реалізація вантажних витрат Монади про те, як вирішити ці проблеми. Знову ж таки, рішення цих проблем, як не дивно, виглядають майже однаково як з модульної, так і з інтегрованої сторони.

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

актори у протоколі проти акторів поза протоколом

Важливо зрозуміти, що вищезазначені процеси наївно враховують лише внутрішніх учасників протоколу. На практиці, зовнішні учасники грають велику роль у ланцюгах постачання цих транзакцій. Саме це ми бачили раніше для (внутрішніх) перевірювачів у традиційному SMR:

джерело: @patrickogrady/rys8mdl5p# Приклад для розриву машинного відтворення стану (DSMR) \"vryx: підсилення розривного машинного відтворення стану\"

на практиці, майже всі валідатори Ethereum замовляють побудову блоку через MEV-Boostз трьох найкращих будівельників (бобер, титан і rsync), які майже всі будують ці блоки. слід зазначити, що бобер і rsync цензорують OFAC-транзакції, тоді як титан цього не робить.

джерело:mevboost.pics

Реле відповідають за реплікацію цих блоків до решти мережі. Вони також досить топ-важкі, з топ-4 операторами (Ultrasound, Bloxroute, Agnostic та Flashbots), які передають більшість блоків. Bloxroute та Flashbots цензурують OFAC-транзакції, тоді як Agnostic та Ultrasound цього не роблять.

джерело:mevboost.pics

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

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

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

узагальнена синхронна композиція

визначення

Чи можемо ми отримати суверенітет та гнучкість, які пропонують модульні ланцюги, але об'єднати їх, щоб вони відчувалися як інтегрований ланцюг? Чи можемо ми мати своє пиріжок і з'їсти його, або ми просто будуємо Солану з додатковими кроками?

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

Усі ці терміни мають різне значення, а деякі терміни часто неправильно використовуються як синоніми. Нам потрібно дати якісь конкретні визначення. Нижче ми визначимо необхідні терміни в контексті крос-чейн компонування.

зверніть увагу, що ми обговорюватимемо «ролапси» протягом всього цього звіту, але багато з цих концепцій так само стосуються інших типів «l2s», таких як валідіуми.Я просто не хочу боротися за те, що таке l2 знову.

У наведених нижче прикладах:

• р_а = rollup a
• r_b = зведення b
• т_{Відповідь 1} = транзакція 1 на r_один
• t_b1 = транзакція 1 на r_б
• b_{Відповідь 1} = блок 1 на r_а
• б_b1 = блок 1 на r_b
  

Зауважте, що тут ми визначаємо «час» як «висоту слота». Час суто відносний до спостерігача. Єдине об'єктивне поняття часу, яке ми маємо, — це відносне впорядкування спільним спостерігачем, тобто спільний консенсус (де цей «консенсус» може бути одним актором або децентралізованим механізмом).

якщо обидва роллапи мають механізм консенсусу, який забезпечує упорядкування, ми можемо твердити:

• б_a1 перед b_a2
• б_b1 перед b_b2

Однак єдиний спосіб стверджувати:

• б_a1одночасно знаходиться в b_В1, та отже
• т_a1і t_b1відбуватися синхронно, якщо
• вони діляться порядком, наданим загальною згодою для цього конкретного слоту.

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

проте слід зауважити, що ми можемо мати асинхронну атомну композабельність. на жаль, часто помічаю, що люди використовують "атомний" і "синхронний" взаємозамінно, але насправді вони різні терміни.

з тим, що зроблено, подивимося, чи можемо повернути синхронну композабельність у модульні ланцюжки. якщо це вдасться, то це може здатися Gate.io значенням інтегрованих ланцюжків. отже, це те, про що ми заглибимось.

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

атомне включення - спільна послідовність

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

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

• атомарно - або всі транзакції будуть включені, або жодної, і
• синхронно - одночасно (висота слоту)

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

Кросчейн анбандлінг

зараз, як саме ми це робимо без повної довіри до будівельника та/або активного пропонента для спільного послідовника? якщо ми просто надсилаємо дві незалежно підписані транзакції (т₁і т₂) для кожного rollup спільний секвенсор все ще може вирішити включити або один, або інший.

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

Нам потрібна набагато сильніша гарантія безпеки, якщо ми хочемо реальної міжланцюгової сумісності. Ми говоримо не тільки про те, щоб взяти гроші у пошуковця. Якби крос-чейн DeFi-контракти будувалися на припущенні, що крос-чейн пакети будуть поважатися, але потім ця довіра буде порушена, результати будуть катастрофічними для цих протоколів (наприклад, у пакеті кросчейн-мосту burn-and-mint ви можете не спалювати, але карбувати кошти на іншій стороні).

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

це означає, що нам потрібно створити нову структуру транзакції для пакетів міжланцюгового зв'язку, які не можуть бути розбундленіНайпростішим рішенням є «створити новий тип транзакції для цих rollups», але це не так просто. Це потребувало б змін ВМ для цих rollups, втрати зворотної сумісності. Крім того, ви б тісно пов'язали rollups, змінюючи їх станові машини таким чином, що кожна транзакція є дійсною лише разом з іншою, що включається.

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

джерело:Бен Фіш

гарантії включення проти гарантій держави

з врахуванням вищезазначеного, ми встановили, як працює лінивий спільний послідовник:

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

На жаль, атомарне включення само по собі є набагато слабшою гарантією. Це зобов'язання до атомарного включення достатньо для того, щоб забудовник мав високу впевненість, що блок cross-rollup, який вони будують, створить бажаний результат, якщо він підтверджений. Забудовник обов'язково знає бажаний результат блоку, оскільки вони виконали його, щоб побудувати його.

але у нас все ще є проблема - як інші можуть з впевненістю знати, яким буде стан?

розгляньте приклад:

• У нас є два роллапи (ra та rb), які використовують один і той же лінивий послідовник
• Я хочу використовувати міст з випаленням та ковтанням між ra → rb, який одночасно випалюється на ra та кується на rb
• контракт мосту монети на rb потребує гарантії переходу стану на ra (знищення) для печатки на rb, але контракт не може знати, чи була токен фактично спалена на ra в момент виконання, тому що він не має доступу до стану ra

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

Просто спільний лінивий послідовник недостатньо для того, щоб дозволити ланцюгам отримувати доступ до станів одне одного під час виконання пакета. Синхронна композабельність вимагає можливості для машина стану кожного ланцюга отримувати доступ до стану іншого ланцюга (наприклад, сам контракт мосту на rb повинен знати стан ra) в момент виконання. Ця можливість саме те, що дозволяє повну композабельність в межах одного інтегрованого ланцюга.

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

щоб виправити це, нам потрібно додати ще якийсь механізм на додаток до спільної послідовності:

як ми вже зазначили, будівельник особисто знає, який буде результативний стан, хоча, якщо в комплект включено атомно. Так як вони можуть надати вірогідне зобов'язання, щоб переконати всіх інших про те, який буде результативний стан, якщо їх угоди будуть включені?

вони загалом мають два варіанти:

• криптогосподарський - будівельник може внести велику кількість капіталу для повного заставного капіталу своїх міжланцюжкових дій.Це часто неефективно і, можна сказати, симулюється композиція, але це корисний приклад для демонстрації функціональності.
• криптографічний - у нас може бути механізм, який забезпечує криптографічні гарантії того, що транзакції приведуть до бажаного стану.

криптоекономічна безпека - облігації будівельника

давайте розглянемо приклад, щоб побачити, як криптоекономіка може симулювати ефекти синхронної композиції. класичний приклад, який використовується, цекрос-ланцюжковий флеш-кредитЯ хочу взяти флеш-кредит на ra, використати його для арбітражу на rb та повернути на ra, все це в одному слоті. Це можливо, якщо ці протоколи DeFi застосовують індивідуальну функціональність між ланцюжками зі спеціальними «банківськими контрактами» на кожній стороні:

Тепер щодо цієї проблеми безпеки - контракт на RA і RB повинен знати стани ланцюга один одного, щоб зробити це безпечно, але ми нічого не зробили для вирішення цієї проблеми. Що ж, криптоекономічне «рішення» тут насправді є досить грубою силою - у вас є супербудівельник, який виступає в ролі постачальника ліквідності та виставляє повну вартість флеш-позики. Якщо транзакції зазнають невдачі, то протокол кредитування все одно зберігає свою частку. Ви можете зрозуміти, чому це не найзадовільніше «рішення».

криптографічна безпека - agglayer

Що це таке

уAggLayer це децентралізований протокол, який надає три основні переваги:

1. безпека для швидкої комбінуваності між ланцюжками - вона створює zk-докази, що забезпечують атомну міжланцюжкову сумісність з криптографічною безпекою на низькій латентності (тобто швидше, ніж блоки Ethereum), коли вона працює асинхронно або синхронно. Дизайн унікально ізолює вади ланцюжків, щоб вона могла підтримувати будь-яке середовище виконання та доказ.
2. функціональність активів міжланцюгової взаємозамінності - вона має спільний міст, щоб забезпечити взаємозамінність активів по всіх агрегаційних ланцюгах (тобто ланцюги, які його використовують), щоб користувачі не опинилися з купою обгорнутих активів. контракт моста знаходиться на ефірі, який єрозрахунковий шар. (Зауважте, що різні ланцюги все ще можуть мати різні припущення щодо безпеки через реалізацію, яка розглядається докладніше нижче.)
3. оптимізація газу - це агрегація доказів aggchains для амортизації постійних витрат на багатьох ланцюгах. спільний депозитний контракт також оптимізує витрати на газ, дозволяючи прямі перекази з L2 на L2 без дотику до L1.

джерело: Брендан фермер, Агреговані блокчейни

щоб уточнити два поширені забобони про те, чим не є agglayer:

• Agglayer - це не просто сервіс для агрегації доказів aggreGate.io - це заплутує, оскільки насправді воно агрегує докази Gate.io, і вони включили «агрегацію» в назву речі. Однак метою agglayer є агрегування ланцюгів. Важливою відмінністю для цілей цього допису є те, що лише агрегація доказів нічого не робить для досягнення гарантій безпеки, які нам потрібні тут.
• Агрегатор та спільні послідовники не є протилежними конструкціями - хоча вони не потребуються використовувати разом, Насправді вони є ідеальним доповненням які надають різні гарантії. Agglayer повністю агностично налаштований щодо того, як секвенуються Aggchains. Він не обробляє жодних повідомлень між ланцюжками, тому він фактично явно покладається на інфраструктуру координації вільного ринку (наприклад, ретранслятори, конструктори, ізольовані секвенсори, спільні секвенсори тощо) для створення ланцюжків.

зараз давайте розберемося, як це працює.

мости шиплять

переход між rollups сьогодні важко. скажімо, ви хочете зробити міст ефір між двома оптимістичними rollups ethereum oru_а і ору_б:

• через власний міст - ви будете платити дорогі газові комісії ethereum l1 (тобто переміщення з oru_один→ ефір + ефір → oru_б) та круглий маршрут займе понад тиждень (через вікно неперебійної довідки).
• прямий роллап → роллап - обгорнений eth, який ви отримуєте на oru_бфактично не буде замінним з власним eth для oru_aЗалежність від шляху проходження через різні мости руйнує функціональність. Наприклад, якщо ORU._aякщо міст був спорожнений, тоді завернутий eth, який ви перейшли до orub, буде не підтримуватися, тоді як місцевий eth на oru_б було б добре. Фрагментація ліквідності – це відстій, тому це не те, чого хочуть користувачі. На практиці користувачі безпосередньо здійснюють мости через постачальників ліквідності. Хтось поставить перед вами ETH на ORU_б і зберігайте свої кошти на ору_a. Вони можуть вивести кошти через рідний міст і чекати, але вони стягуватимуть високу комісію за ризик і високу вартість капіталу, який вони понесуть.

можливо, ви думаєте, що zk rollups вирішують це відразу, але насправді це не так. наївні реалізації все ще потребують від вас подавати l1-транзакції, що знову є дорогим і, як правило, досить повільним (наприклад, через час остаточності ethereum, час генерації доказів, як часто публікуються докази на практиці і т. д.).

Користувачі не хочуть мати справу з цим. Вони хочуть просто мати кошти та використовувати додатки. Містки повинні бути повністю абстраговані - активи повинні бути замінними та швидко, дешево та безпечно переміщуватися.

Ось де використання спільного контракту моста стає на допомогу. Спільний контракт моста відкриває двері для ланцюгів, які використовують його, щоб мости прямо між собою, не проходячи через l1.

токени також можуть бути замінними через aggchains в результаті. перетин ефіру з р_один→ r_бабо r_c → r_bGate.io спалює та штампує однакові токени. Це не обгортковий актив з блокуванням та штампуванням. Це нативний eth. Це можливо завдяки тому, що всі активи знаходяться в ескароу разом та вирішуються через єдиний міст. Це серйозна проблема для l2, яку потрібно вирішити сьогодні.

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

песимістичні докази

AggChains надсилають свої оновлення стану та докази вузлам стейкінгу Agglayer, які впорядковують їх, генерують зобов'язання до всіх повідомлень та створюють рекурсивні докази. потім agglayer генерує один доказ zk aggreGate.iod (який вони називають "песимістичний доказ”) для вирішення на ефірі для всіх aggchains. оскільки агрегація доказів тут амортизує витрати через довільну кількість ланцюгів, практично з точки зору витрат розміщувати їх на ефір для швидкого вирішення якнайшвидше. песимістична програма доказів написана в звичайному коді ржавини, використовуючиzkvm sp1 Succinctдля спрощення розробки та досягнення високої продуктивності.

ці песимістичні докази підсилюють:

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

завдяки цьому agglayer забезпечує, що розрахунок відбувається на Ethereum лише тоді, коли виконуються вищезазначені умови. Якщо умови не виконуються, то відповідні ланцюжки не можуть вирішити справу. Таким чином, agglayer може дозволити координатору (наприклад, спільному послідовнику або будівельнику) передавати повідомлення між ланцюжками з низькою затримкою без того, щоб довіряти цьому координатору з питань безпеки.

швидка та безпечна міжланцюгова взаємодія

Aggchains можуть використовувати надані тут гарантії як в асинхронному, так і синхронному середовищі взаємодії, щоб виражати обмеження щодо дійсності блоку відносно інших rollups.

Це дозволить користувачам надсилати перехресні пакети, які повинні бути успішно виконані атомарно з обох сторін. Це не просто атомарне включення. Фактично ви забезпечуєте успішний результат стану обох сторін. Це ідеально підходить для доповнення того, що ми описали як відсутність гарантій атомарного включення в спільний послідовник.

джерело:Брендан фермер, Агреговані блокчейни

беручи наш приклад з раніше:

• у нас є дві ролапи (r_aі р_б) спільний лінивий послідовник та agglayer
• Я подаю крос-цепочковый пакет для одновременного сжигания эфира на R_aта монетизувати eth на r_б
• супер будівельник будує блок для обох ланцюгів, роблячи це, на що зобов'язується спільний послідовник
• Контракт на карбування мосту на R_бможна оптимістично виготовити eth у відповідності до стану r_a (у цьому випадку успішне виконання запису ETH)
• ці блоки та докази надсилаються до agglayer, що підтверджує, що обидві ланцюги діяли валідно (як незалежно, так і відносно один до одного) та що спільний міст був використаний безпечно

щоб це було вирішено успішно для ефіріуму, обидва ланки пакета повинні були виконані належним чином. якщо будь-яка сторона зазнає невдачі, то блоки будуть недійсними і не зможуть бути вирішеними. це означає, що якщо, скажімо, спільний послідовник підписав блок, де ефір не було спалено на r_один але викарбувано ETH на R_б, тоді цей блок буде перерозгорнутий. це забезпечує безпеку всіх ланцюгів та запобігає недобросовісним міжланцюжковим діям вирішуватися.

Є два моменти, про які слід пам'ятати щодо цих реорганізацій:

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

ці реорганізації повинні бути надзвичайно рідкісними та мінімальними через вищезазначені пункти, але через це агрегаційні ланцюги будуть повністю контролювати, з якими ланцюгами вони хочуть компонувати атомарно та з якими довірчими припущеннями. наприклад, р_aможе прийняти стан ланцюжка від r_bщоб компонувати на основі консенсусу їх послідовника, але для р_cможливо, вони також можуть попросити подати доказ, і для r_d Можливо, вони хочуть, щоб вони криптоекономічно убезпечили всі крос-чейн атомарні залежності. Кожна мережа може зробити свої власні компроміси, які можна налаштувати, для низької затримки та жвавості. Agglayer просто забезпечує максимально гнучку та мінімально продуману основу для безпечної крос-чейн взаємодії ланцюгів.

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

виявлення несправностей для гетерогенних довідників

Важливо, що AggLayer унікально дозволяє повністю гетерогенні ланцюжки. Ви можете мати AggChain з будь-яким користувацьким vm, prover, da layers тощо, одночасно безпечно ділитися мостом з усіма.

як це можливо? причина, чому це зазвичай неприйнятно, полягає в тому, що один несправний учасник (наприклад, з помилкою в схемі) зазвичай може просто обманути міст і вичерпати всі кошти. Ось тут і входить в гру вищезазначений міжланцюжковий доказ бухгалтерії. Ці докази забезпечують дотримання всіх мостових невідмінностей, так що навіть у випадку недостовірного довідника можуть бути витрачені лише кошти, внесені на порушену ланцюг. Вада повністю ізольована.

достовірна нейтральність

цей тип інфраструктури значно збагачується вірогідною нейтральністю, тому Повністю відкритий вихідний код Ifor Agglayer є нейтральною територією.У подібному дусі, agglayer буде використовувати eth як єдиний токен газу для оплати комісій за агрегацію доказів.

Це, безумовно, не ідеально. Особливо на початку, це не буде повністю вірогідно нейтральним. Ймовірно, на шляху до кінцевої незмінності та увіковічення як громадське благо, буде можливість оновлення контрактів.

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

Aggchains не потребують жодної конкретної віртуальної машини, середовища виконання, секвенсора, рівня DA Layer, токена стейкінгу, токена GAS або загального управління. Ланцюжки можуть піти, коли захочуть. Вимог щодо частки доходу немає. Вам не потрібно розгортати як L3 в чужому ланцюжку.

Причинами для запуску L3 поверх звичайних L2, на мій погляд, в основному були пластирі, в той час як будуються архітектури, подібні до Agglayer. Однак, щоб було зрозуміло, це цілком вагома причина запустити їх сьогодні. V1 Agglayer – це простий контракт на спільний міст. Версія V2 з агрегацією доказів і можливістю безпечної взаємодії з низькою затримкою навіть не працює. Ви не можете очікувати, що люди чекатимуть роками, коли у них виникне потреба доставити річ сьогодні, яка забезпечить їм найшвидший розподіл.

доказ в реальному часі

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

• у нас є два ролапи (r_aі r_bспільний лінивий послідовник
• Я хочу використовувати міст між ra → rb, який одночасно знищує на ra і виготовляє на rb
• супер-будівельник створює перехресний блокчейн, який включає пакет таких перехресних транзакцій. всередині блоків будівельник включає доказ переходу стану, що включений у інший роллап.

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

Для реального доказу ми ідеально хотіли б, щоб час доказу був лише невеликою частиною загального часу слота, тим самим максимізуючи «вікно синхронізації». Це частина часу слота, протягом якої ви можете обробляти транзакції, які працюватимуть синхронно між ланцюжками, оскільки вам потрібно відвести достатньо часу в слоті, щоб створити доказ і занести його в блок.

джерело: Джастін Дрейк, реальний доказ

Зауважте, що тут ми неявно об'єднаємо або зіставимо будівельників і доказів. У будівельників є чіткий стимул оптимізувати швидкість перевірки, щоб вони могли нарощувати до останньої секунди і вміщати якомога більше у своєму блоці.

джерело:Джастін Дрейк, доказ в реальному часі

Якщо цей високий стимул для доведення в реальному часі все ж матеріалізується в найближчі роки, ми також повинні зазначити, що це, звичайно, зовсім не дружнє до децентралізованого доведення. Докази повинні бути відносно централізованими, коли вони об'єднуються або розміщуються з будівельниками.

зведення

універсальна синхронна композабельність дійсно крута, але не зовсім зрозуміло, наскільки вона насправді цінна. Інтернет повністю асинхронний, і ви цього ніколи не здогадаєтеся. Це тому, що він швидкий, а складність абстрагована. Це все, чого хочуть користувачі.

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

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

Особисто я вважаю, що найкращим аргументом на користь необхідності USC є те, що на практиці це призводить до кращого UX та Devex. Неможливо заперечувати гігантську користь, яку це принесло таким екосистемам, як Solana. Однак, сподіваюся, це скоріше проблема сьогодення, а не вічна.

просто факт того, що це також трохи складно для кого-небудь міркувати на цьому етапі. це не бінарний «все в криптовалюті синхронне» або «все асинхронне». я вважаю, що ми фундаментально повинні вирішити це і прийти до останнього, але обидва можуть існувати на ад-хок основі.

розвиток на основі Ethereum

Гаразд, тепер ми повинні мати гарне уявлення про простір рішень для вирішення проблеми фрагментації у зведеннях. Наступне питання: як ми повинні залучати до всього цього базовий шар? Яка роль Ethereum тут?

Ми будемо використовувати наступні скорочення:

• bl - базовий рівень
• Зведення на основі BR
• попередні підтвердження - попередні підтвердження

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

ролі, засновані на ванілі

початкові реалізації rollup кілька років тому фактично булипланується брати, але були відмовлено на користь централізованих послідовників для низької латентності та високої ефективності. те, що ми зараз називаємо послідовним секвенуванням, Віталік називав «повний анархія«в той час. це було досить непрактично та неефективно до еволюції інфраструктури ethereum pbs (з витонченими будівельниками).

Потім BR знову опинилися в центрі уваги в березні 2023 року, де вони були визначені наступним чином:

«ролап вважається базовим або l1-послідовним, коли його послідовність зумовлена базовим l1. Конкретніше, базовий ролап - це такий, в якому наступний пропонувач l1 може, у співпраці з l1 пошуковиками та будівельниками, дозволено включити наступний блок ролапу в рамках наступного блоку l1.»

вони повинні пропонувати наступні переваги:

«Секвенування таких зведень — секвенування на основі — максимально просте і успадковує L1 жвавість і децентралізацію. Крім того, базові зведення особливо економічно вирівняні зі своєю базою L1».

Зокрема, ви отримуєте реальний захист ефіріуму:

«ви успадковуєте опір до цензури та лайвнес ефіріуму. Таким чином, у вас не тільки є гарантії проведення розрахунків ефіріуму, але у вас також є опір до цензури в реальному часі, а не затриманий, як ви знаєте з вихідним виходом, але саме в реальному часі.

Бути базовим роллапом - це логічний дизайн, якщо ви вже вибрали базовий рівень:

«Ethereum максимізує ці дві властивості, безпеку та надійний нейтралітет, це майже визначення права на зведення... Ролап – це той, який вже купив припущення про безпеку Ethereum. Ви не додаєте нові припущення щодо безпеки. Ви не потрапляєте в найслабшу ланку. Ви просто повторно використовуєте існуюче припущення про безпеку. І по-друге, ви вже прийняли Ethereum як надійно нейтральну платформу, інакше ви б вибрали інший ланцюг. А тепер ви можете запитати себе, чому всі не використовують секвенування першого рівня?»

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

однак, послідовний секвенування все ще має свої недоліки, що є точночому ролапи зазвичай реалізовані зі своїм власним послідовником:

• Швидкі preconfs - Користувачі ролапу не хочуть чекати 12S+ на блоки Ethereum.
• безпечні підтвердження передбачувані - іноді блоки Ethereum переорганізовуються, тому користувачам доводиться чекати ще довше, щоб бути в безпеці, що, знову ж таки, не подобається користувачам. послідовники можуть надати передбачувані підтвердження, які не залежать від незавершених блоків Ethereum і, отже, не потребують переорганізації навіть якщо сам Ethereum досвідчує коротку переорганізацію.
• ефективна пакетна публікація - послідовники можуть пакувати велику кількість даних, стискувати їх і періодично публікувати в bl в оптимізованому за вартістю способі (наприклад, забезпечуючи повне використання блобів).

розвиток rollups + передконфи

так отже, чи можемо ми мати нашу торт і з'їсти його теж? введіть на основі попередньої конференції.

ми коротко пояснимо інтуїцію за основні попередні конфігурації тут, щоб ми могли порівняти brs + preconfs проти традиційних rollups. пізніше ми повернемося, щоб докладніше проаналізувати preconfs загалом (тобто як br preconfs, так і bl preconfs на транзакціях ethereum l1).

Основна ідея полягає в тому, що br preconfs повинні надходити від bl пропонентів. Щоб забезпечити preconfs, ці пропоненти повинні внести якусь заставу (наприклад, переставлення) та погодитися на додаткові умови зменшення (тобто те, що надані ними preconfs дійсно потраплять на ланцюжок, як обіцяно). Будь-який пропонент, який має намір це зробити, може діяти як br послідовник і надавати preconfs.

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

Однак очікується, що існуючі ретранслятори візьмуть на себе і цю роль. Gate.ioway буде взаємодіяти тільки між користувачем і ретранслятором, тому додавання ще однієї незалежної сутності лише додає складності та затримки (хоча затримку також можна усунути за допомогою спільного розміщення). Ретранслятору вже довіряють розробники та ініціатори, тому ми додамо сюди ще одну вимогу до них щодо довіри від користувачів.

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

в будь-якому випадку, важним є те, що будь-який префікс швидший за консенсус Ethereum (12s) потребує довіреної сторонньої особи (ТСО). незалежно від того, чи ваш ТСО є перевіреним валідатором, стейкомвиконання аукціонуПереможець, deleGate.iod Gate.ioway, або будь-що інше - це фундаментально не може забезпечити безпеку ефіріуму в реальному часі. чи coinbase дає вам «заснований попередній конф» як пропонент ефіріуму, або «традиційний попередній конф» як послідовник rollup - ви довіряєте coinbase. Вони так само можуть внести заставу з якихось eth, але в обох випадках це незалежно від безпеки консенсусу ефіріуму.

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

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

для brs - ttps надають швидкі preconfs, а bl забезпечує кінцеву безпеку.

ролапи на основі + резервне значення на основі

Зараз розглянемо традиційний (тобто не заснований) rollup. Його власний послідовник (незалежно від централізованого чи децентралізованого) надає швидкі передбачення. Пізніше їх користувачі отримують повну безпеку Ethereum з певною затримкою. Це включає живість (ріст головного журналу + стійкість до цензури), яка походить з якоїсь форми.примусове включенняабоЗапасний BLмеханізм.

як я відзначив вЧи успадковують ролапи безпеку?:

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

роллапи також можуть надавати «щасливий шлях» більш вільне правило підтвердження (тобто послідовникам) для кращого користувацького досвіду, але вони залишають резерв у випадку невдачі. якщо ваш послідовник зупиниться, ви можете продовжувати рухатися.

зверніть увагу, що час до остаточної безпекиосновна змінна для оптимізації тут:

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

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

у цьому дусі,Sovereign labs має дизайняке робить наступне:

• послідовне упорядкування з обмеженим доступом - ролапи встановлюють послідовника з обмеженим доступом, чиї транзакції обробляються негайно після їх включення в блокчейн. через наявність блокування запису стану ролапа вони можуть надати надійні попередні підтвердження швидше, ніж час блоку блокчейна.
• поширена послідовність - користувачі також можуть надсилати транзакції безпосередньо до своїх bl, але вони обробляються затримкою n блоків (де n є досить малим). Це значно зменшує "час до остаточної безпеки", і насправді вони навіть називають цей дизайн "поширена послідовність з м'якими підтвердженнями" через це! (зауважте, що ця визначення brs суперечить визначенню, яке ми надали раніше, тобто пропонент bl повинен мати право послідовності br або бути делеГейт.иодом для них.)

для небрс - ttps забезпечує швидкі попередні підтвердження, а bl забезпечує кінцеву безпеку.

чому?

як ми бачимо, обидва описані вище шляхи потім дають одинаковий ефективний результат:

Ці brs з попередніми конфігураціями більше не забезпечують простоти або реального захисту в реальному часі Ethereum. Тоді яка тепер точка усього цього? Чому б нам просто не стиснути резервні копії на «традиційних» rollups? Що взагалі таке «based rollup» на цей момент?

це насправді повертається до могоДоказ управлінняпост з минулого року, де я обговорював основні випадки використання для специфічного повторного стейкінгу Ethereum:

1) технічний (зобов'язання заявника) - немає іншого виходу - якщо ви хочете вірного зобов'язання до порядкування блоку Ethereum, воно повинно надійти від валідаторів Ethereum.MEV-Boost++ - це один приклад гіпотетичного застосування, яке може потрапити в цей список.

2) соціальне - я розглядаю вирівнювання ефіріуму як основний випадок використання для більшості програм перерозподілу сьогодні, а не об'єднання економічної безпеки чи децентралізації. це нагадує сказати " подивися, ми проект Ethereum!” це в основному та ж сама причина, чому ланцюги продовжують називати себе ethereum l2sнезалежно від архітектури.

мы можем модернизировать это в контексте вопроса, какова ценность "br + preconfs" перед "традиционным роллапом + быстрым откатом"?

1) технічні (зобов'язання пропонента) - ethereum brs з попередніми установками мають одну фундаментальну технічну перевагу - вони можуть отримати достовірне зобов'язання від поточного пропонента ethereum щодо включення та упорядкування вмісту блоку ethereum. Це потенційно цінно за тими ж самими причинами, з яких ми потенційно хочемо, щоб кілька rollups поділяли секвенсор. Якщо пропонент bl також є пропонентом br (тобто секвенсором), то вони можуть забезпечити ті ж самі атомарні гарантії включення з bl, що із з якими-небудь rollups, які ділять секвенсор. У них є монополія на обидві ланцюги. Тепер, наскільки це цінно? Ми повернемося до цього трохи пізніше.

2) соціальна (вирівнювання / достовірна нейтральність) - любіть її або ненавидьте, Узгодження Ethereumє однією з основних переваг, щоб бути br. Буду чесним, я не дуже багато знаю про Taiko, крім того, що вони br хлопці, і, напевно, я б не знав, хто вони були, якби вони не були br хлопці. Кожен хоче якісну спільну маркетингову діяльність. Є значення в тому, щоб бути першими тут, але я підозрюю, що це не постійна цінність і не розповсюджується на багатьох майбутніх потенційних br. Так само, ми всі чули про перші кілька avs, але ви можете назвати всі поточні? Я не можу.

На більш високому рівні ви не отримаєте всі зведення Ethereum, щоб вибрати (гіпотетичний) «Sharemism Shared Sequencer» або «Arbitrum Shared Sequencer». Однак у вас є кращі шанси змусити їх усіх вибрати «Спільний секвенсор Ethereum». Ні нового токена, ні нового бренду, ні нового консенсусу. Якщо ви вважаєте, що для всіх L2 Ethereum цінно об'єднатися для секвенування, то цей надійний нейтралітет потенційно є найсильнішою точкою Шеллінга для досягнення цієї мети.

Ця достовірна нейтральність, ймовірно, найцінніша для розробників Rollups, які намагаються привернути користувачів з різних екосистем (наприклад, додатки з базовою інфраструктурою, такою як ENS). Вони можуть бути схильні утримуватися від використання оптимізації секвенатора, якщо це відштовхне користувачів Арбітруму, або навпаки.

мы рассмотрим каждый из них более подробно ниже.

достовірна нейтральність

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

вірогідно нейтральний br легко розробити у ванільному випадку, але, як ми відзначили, ніхто справді не хоче їх. preconfs обов'язково вимагають від пропозиції вибору додаткових умов зниження. ці додаткові умови зниження вимагають від пропозиції використання додаткової системи (наприклад, потенційного eigenlayer restaking, Симбіоз, або інший стандарт), щоб зробити зобов'язання. Роллап може радіти можливості вибору нейтрального «ethereum sequencer» в абстрактному режимі, але нейтральність вірогідно втрачається, якщо ви використовуєте приватно фінансовані проекти, можливо навіть з власними токенами.

існують кілька відкритих питань щодо застави тут:

розмір застави

ранні проекти передбачали, що пропонуючі особисто повинні будуть внести надзвичайно велику суму застави в розмірі 1000 eth. проблема полягає в тому, що фактично пропонуючий завжди може відмовитися від своєї обіцянки делегувати.io і самостійно побудувати блок, заперечуючи попередні підтвердження. це може бути надзвичайно цінно, і 1000 eth зручно перевищує найвищі спостережувані платежі, які пройшли через mev-boost з моменту його заснування. недолік полягає в тому, що це, звісно, створює високий бар'єр для вступу для менших пропонентів, тоді як більші (наприклад, coinbase) могли б розумніше внести 1000 eth, отримуючи винагороди за всю свою ставку ( >13% від загальної кількості ETH у стейкінгу) тому що реєстранти можуть внести один заставний внесок за всіх своїх валідаторів. єІнші ідеї, які дозволять пропонувачам з набагато меншими зв'язками, хоча, звичайно, вони супроводжуються певними компромісами. простір для дизайну тут просто невизначений.

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

джерело:Барнабе монно, від mev-boost до epbs до aps

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

тип застави

Vanilla ETH, ймовірно, є єдиною надійно нейтральною заставою в цій ситуації. Однак, природно, виникне бажання використовувати більш капіталоефективні активи (наприклад, Steth). Є кілька ідей, щоб андеррайтер займався цим перетворенням, як описано в mteam тут.

платформа

Це було б не дуже «достовірно нейтрально», якби «преконференції на основі Ethereum» були більше схожі на «Preconf на основі Eigenlayer» або «Preconfs на основі симбіотичних ліній». Є команди, які планують рухатися в цьому напрямку, але використання такої платформи не є суворою вимогою. Можна створити загальний і нейтральний стандарт для всіх, і така система, здавалося б, краще позиціонується для загального прийняття як найбільш обґрунтований варіант.

для того, щоб основані на концепціях попередньої конференції дизайни могли бути "по суті нейтральними", буде потрібно прийняття стандартів громадського блага.

передпідтвердження

включення проти попереднього підтвердження стану

Тепер ми розглянемо преконфі більш детально. Хоча раніше ми обговорювали конкретний тип преконф (BR Preconfs on state), ми повинні зазначити, що вони є повністю загальним поняттям. Ви можете пропонувати преконфи на транзакції BL на додаток до BRS, і ви можете запропонувати різні сильні сторони преконфів:

• включення попередніх конфігурацій - слабке зобов'язання, що транзакція врешті-решт буде включена в ланцюжок.
• state preconfs - найсильніше зобов'язання, що транзакція врешті-решт буде включена в ланцюжок та гарантія отриманого стану.

останнє (попередні конфігурації) - це, звісно, те, що користувачі хочуть бачити у своїх гаманцях:

Я обміняв 1 ETH на $4000 USDC та заплатив 0,0001 ETH комісії

не включення попередніх конфігурацій:

моя транзакція, спробуючи поміняти 1 eth на $4000 usdc і заплатити до 0.0001 eth за комісію, врешті-решт з'явиться на ланцюгу, але можливо вдасться, можливо ні, побачимо

Однак, слід зауважити, що преконфи включення фактично взаємозамінні з преконфами станів у випадку дій користувача, вчинених над неспірним станом (наприклад, прості передачі, коли тільки сам користувач може визнати транзакцію недійсною). У цьому випадку обіцянка про те, що, наприклад, «Переказ Аліси USDC до Боба буде включений до наступних кількох блоків», є достатньою для гаманця, щоб просто показати користувачеві «Ви відправили свій USDC Бобу».

Не дивно, що більш міцні зобов'язання (державні попередні конференції) важче отримати. Основним чином, вони потребують...достовірне зобов'язаннявід суб'єкта, який наразі має монополію на пропозицію блоків (тобто блокування запису стану ланцюжка). у випадку ethereum l1 preconfs це завжди поточний пропонувач ethereum l1. у випадку br preconfs це, очевидно, наступний пропонувач ethereum l1 в перегляді br (що робить їх поточним пропонувачем для br), як ми побачимо нижче. пропонувач та послідовник, як правило, є взаємозамінними термінами, причому перший частіше використовується в контексті l1, а другий - в контексті l2.

цінові передвиборчі

ще одна велика розбіжність, яку нам потрібно зробити, це який тип стану торкаються ці попередні конфігурації:

• Позаконфліктний стан - нікому іншому не потрібен доступ до цього стану (наприклад, Аліса хоче перевести USDC на Bob)
• Спірний стан - інші хочуть отримати доступ до цього стану (наприклад, свопи в пулі ETH/USDC AMM)

Preconfs - це обмеження того, який блок в кінцевому підсумку може бути вироблений. Якщо інше рівне, обмеження простору пошуку для будівельників неодмінно може лише зменшити потенційну вартість, яку вони можуть захопити, розмістивши її. Це означає, що менше значення повернеться пропоненту. Щоб зробити це стимулюючим, Gate.ioway потрібно встановити плату за попередній запис ≥ потенційний mev, втрачений внаслідок обмеження результату.

Це досить просто, коли втрата MEV становить приблизно 0 (наприклад, у випадку передачі USDC). У цьому сценарії стягнення невеликої фіксованої плати може бути розумним кроком. Але у нас є велика проблема - як ми оцінюємо попередні підтвердження в спірних станах? Здається, що оцінка попередніх підтверджень заздалегідь проти оцінки в останній момент приносить менше прибутку. Усе інше рівне, найбільш вигідно будівельнику зачекати до останньої можливості, щоб захопити й точно оцінити MEV.

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

Попередні конфлікти на спірній державі, які транслюються протягом блоку, конфліктують з тим, як будівельники створюють блоки. Цінові попередні конфлікти точно вимагають оцінки в реальному часі впливу MEV на його включення зараз, а не відкладення, що означає виконання та моделювання можливих результатів. Це означає, що Gate.ioway зараз потрібно бути високорозвиненим пошуковиком/будівельником.

мы уже предполагали, что Gate.ioway и ретранслятор объединятся. если им нужно будет непрерывно ценить предварительные конфигурации, то они также объединятся с builder. мы также приняли, что usc ускорит слияние builder и prover. также кажется, что аукціони виконання продаватиме права оферента безпосередньо досвідченим суб'єктам (ймовірно, забудовникам), здатним встановити на них ціну.

це ставить усю цілісність ланцюга поставок транзакцій ethereum l1 та br в одну коробку, яка має монопольний запис-блок на стан всіх ланцюгів протягом цього періоду.

Правила впорядкування в службі preconf незрозумілі (наприклад, чи завжди вони запускають fcfs, чи замовляють їх іншим чином). Також потенційно можливо, що Gate.ioway запустить аукціон для всіх преконфів (наприклад, дозволивши пошукачам робити ставки на преконфи), хоча незрозуміло, як виглядатиме такий дизайн, і це обов'язково означатиме більшу затримку.

проблема справедливої обміну

існує проблема чесної обміну з попередніми конфігураціями, де Gate.ioway фактично не має прямого стимулу для випуску попередніх конфігурацій.

розгляньте наступний приклад:

• нинішній Gate.ioway має монополію 12s
• користувач подає запит на попередню транзакцію прямо на початку слота (t = 0)
• Gate.ioway чекає до t = 11.5, щоб випустити всі передплати, які вони зробили під час їхнього слоту, залишаючи 500 мс буфер, щоб усі вони увійшли в їх блок. У цей час вони можуть вирішити, які передплати включити, якщо вони прибуткові, і які виключити.

у цьому сценарії користувач може оплатити передплату, навіть якщо він фактично отримує її лише в кінці слоту. Gate.ioway також може просто відмовитися включити її в кінці слоту, якщо вони вирішили, що це не прибутково. це утримання Gate.ioway не є об’єктивно атрибутованою помилкоюале це може бути міжсуб'єктивно приписуване).

Фактично, є стимул для Gate.ioways затримувати передплати до кінця.Де є асиметрія інформації, там і є MEV. збереження транзакцій в приватності дозволяє будівельнику мати більш актуальний огляд стану світу, що дозволяє йому краще оцінювати ризик і здійснювати перехоплення mev. тут немає згоди щодо набору preconfs, які надаються користувачам, тому Gate.ioway не може бути притягнутий до відповідальності.

Тут мусили б бути встановлені стандартита очікування від попереднього підтверджувача негайно публікувати усі попередні підтвердження. Це надасть користувачам те, що вони хочуть негайно, і дозволить іншим бачити, що Gate.ioway надає очікувані послуги. Якщо вони не зроблять цього в майбутньому, то користувачі не будуть їм довіряти та платити за попередні підтвердження. Репутація Gate.ioway має значення. З цього приводу можна сказати, що вона також може бутинадзвичайно ціннийбути недостойним тут і повернутися проти попередніх переконань.

l1 базовий рівень попередні конфігурації

з урахуванням загальних точок попередньої конференції, ми тепер обговоримо дрібниці попередніх конференцій l1. хоча ми не згадували їх раніше, є проекти, які будують їх, і їх взаємодія з попередніми конференціями br буде важливою.

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

важливо відзначити тут, щоБолт v1описане тут підтримує лише просте включення транзакційних попередніх конфігурацій для несуперечливого стану, де лише користувач може анулювати попередню конфігурацію. Як ми вже обговорювали, це найпростіші та найслабкіші зобов'язання для надання.

Усі ці преконф-команди мають більші амбіції (наприклад, державні преконференції, аукціони з частковими блоками, аукціони слотів або аукціони з частковими слотами), тож що їх стримує?

• відповідальність - порушення зобов'язань повинні бути доведені через onchain для об'єктивного зменшення. Досить легко довести включення транзакції, але не так ясно, як забезпечити виконання інших зобов'язань, таких як аукціони слотів.
• вимоги до капіталу - надання довільних зобов'язань означає, що вартість порушення зобов'язання може бути як завгодно високою. Gate.ioways, швидше за все, в кінцевому підсумку доведеться здійснювати стейкінг величезних сум (наприклад, тисячі eth), щоб надати їх. Вони цілком можуть бути об'єднані, приносячи користь найбільшим організаціям (наприклад, великим торговим фірмам або Coinbase) і залишаючи поза увагою менші організації.
• ціноутворення - є багато відкритих питань щодо того, як встановлювати ціну на щось, подібне до постійно транслюваного попереднього конфігурування стану, навіть якщо ми вирішимо, що це можливо та цінно.
• участь у мережі - це, можливо, найважливіший та фундаментальний аспект. Як ми вже зазначили, лише поточний пропонувальник, який має блокування запису в стані, може забезпечувати зобов'язання, такі як попередні підтвердження стану. В теорії 100% пропонувальників можуть вибрати цю систему та імітувати це. У практиці це не станеться.

Mev-Boost, простіший продукт з багаторічним послужним списком, який неймовірно прибутковий у використанні, має >92% участідля контексту (імовірно ще трохи вище, оскільки це не враховуємінімальна ставка. нова передконфігурація обслуговування, безумовно, отримає набагато менший рівень участі. але навіть якщо вона зможе вийти на рівень близько 90%, це не здається корисним продуктом для звичайних користувачів. ви не можете казати користувачам 10% часу "вибачте, зараз немає передконфігурацій доступних, перевірте через хвилину."

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

попередні конфігурації на основі rollup l2

br preconfs must come from the bl proposers (that’s why they’re “based”). this requires them to stake some collateral and opt into additional slashing conditions (i.e., that the preconfs they provide will indeed make it onchain as promised). any proposer willing to do so can act as a br sequencer and provide preconfs.

Головне, ці br preconfs - це не просто preconfs включення, а preconfs включення в стан. Це можливо, оскільки brs обирають дизайн, в якому вони надають монополію на ротаційного секвенатора bl пропонентам, які підписуються на Gate.ioways.

сьогодні один ethereum-перевірник служить пропонентом для кожного слоту, і графік пропонентів завжди відомий для поточної епохи та наступної. епоха складає 32 слоти, тому ми завжди знаємо наступних 32-64 пропонентів в певний момент часу. дизайн працює, надаючи наступному активному послідовнику (тобто наступному послідовнику в перегляді) монопольні права на послідовне виконання транзакцій для brs, що вибрані до цієї системи попередньої конфігурації. Gate.ioways мають підписати для продовження стану ланцюгів br.

Зверніть увагу, що кожен пропонувач (навіть ті, хто не обрав варіант бути Gate.ioway), має право, але не зобов'язання включати транзакції, які отримали попередню підтвердженість від послідовників (тобто ті пропонувачі, хто обрав варіант бути Gate.ioway). Вони можуть діяти як включальник, поки в них є повний список транзакцій, які отримали попередню підтвердженість до цього часу (послідовник може створити блок bl, в якому є транзакції br та розповідати їх).

джерело: Секвенування Ethereum, Джастін Дрейк

потік транзакцій працює наступним чином:

1. br користувач надсилає свою транзакцію на наступного послідовника в передперегляді (пропозиціонера слоту n+1 на малюнку нижче)
2. послідовник негайно надає попереднє підтвердження для отриманого стану (наприклад, користувач поміняв 1 eth на $4000 usdc на br і заплатив 0.0001 eth комісії)
3. На цьому етапі будь-який включений може включити послідовну транзакцію (ініціатор слота N робить це на зображенні нижче)

Target: Послідовність Ethereum, Джастін Дрейк

Якщо інші включення не включають преконфи, то секвенсор, який їх дав, може просто включити їх ончейн, коли настане їхня черга як ініціатора BL. Наприклад, на зображенні вище, скажімо, slot n includer вирішив не включати преконфи, які видавав секвенсор слота N+1. Тоді секвенсор слота N+1 відповідатиме за включення всіх преконфів, які він видав під час слота N, і слота N+1, коли він надсилає свій блок BL для N+1. Це дозволяє секвенсеру впевнено видавати преконфи за повний період між ними і тим, хто був останнім секвенсором.

для спрощення пояснень, ми просто припустили, що пропонувач l1 виконає цю передумову. як описано вище, це, однак, малоймовірно. для цього знадобиться складна структура, яка буде встановлювати ціну на передумови, запускати повні вузли для всіх brs, мати захист від dos і достатню пропускну здатність для всіх br транзакцій і т. д. ethereum хоче зберігати валідаторів дуже нескладеними, тому ймовірно, що пропонувачі позначать передумови іншій структурі, так само, як вони сьогодні позначають повне виробництво блоків l1 через mev-boost.

Ініціатори можуть deleGate.io до Gate.ioways за допомогою ончейн або офчейн механізмів, і це можна зробити аж до початку слота. Як зазначалося раніше, на практиці цю роль, швидше за все, візьмуть на себе естафети. Також можливо, що їм також доведеться об'єднатися з будівельниками.

джерело: На основі послідовного розташування, Джастін Дрейк

як описано раніше, тільки одне сутність може бути делегованою, щоб бути Gate.ioway в певний час. це необхідно для забезпечення надійних передбачень стану. uis (наприклад, гаманці, як metamask) були б схилялися до того, хто є наступним Gate.ioway, і вони б відправляли користувацькі транзакції туди.

ethereum rollups - наскільки вони будуть засновані?

з достатнім фоном зараз на місці - чи повинні ефірні роллапи бути засновані? тут насправді є два вбудовані питання:

1. чи повинні багато ефірних роллапів ділитися послідовником?
2. якщо так, чи він має бути базовим послідовником (тобто залучати пропозиції ethereum bl та оточуючу інфраструктуру mev)?

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

Незважаючи на це, давайте просто припустимо, що умова 1 виконується. Я думаю, що на даний момент у нас є переконливі докази того, що існує достатній попит на використання децентралізованого спільного секвенсора. Навіть якщо вони не переймаються «спільним аспектом», я думаю, що є неймовірно висока цінність у можливості придбати децентралізований секвенсор як послугу з полиці (насправді, я думаю, що це найбільша цінність тут).

Тепер, чи повинен цей спільний секвенсор бути секвенсором на основі Ethereum?

технічні (зобов'язання ініціатора)

Я не бачу вагомих технічних аргументів для використання послідовника на основі Ethereum. Будь-яка взаємодія між BRS та Ethereum L1 буде надзвичайно обмеженою через нездатність надійно виконувати проти L1 (тобто не постійне маючи блокування запису в L1), довгі часи блоку (12s) і те, що транзакції BR, які дійсно бажають взаємодіяти з L1, потім повинні реорганізуватись поруч з ним. Тут немає безкоштовного обіду. Це не розблоковує жодних цінних продуктів для користувачів порівняно з будь-яким іншим зовнішнім спільним послідовником.

Основна цінність, яку я бачу, полягає в тому, що додавання Ethereum L1 до цього більшого комбінаторного аукціону може призвести до створення вищої загальної вартості Gate.io.дозволяти l1 захопити більше значення. доводячи цю логіку до крайності, ми, можливо, маємо виставити все на світі на одній аукціон. Цей універсальний аукціон також повинен включати квитки на концерт Тейлор Свіфт. Я ще не зовсім там.

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

На практиці існує деякий значущий ризик для мене, що це насправді може бути надто контрпродуктивним для Ethereum, оскільки ця базова передконфігурація, здається, є потенційно акселераціоністичною щодо інфраструктури MEV, коли ланцюг поставок Ethereum вже дещо крихкий. Це загрожує децентралізації мережі та опору перед цензурою - самі речі, які роблять її цінною з самого початку.

соціальна (достовірна нейтральність)

Я бачу дійсно обґрунтований соціальний аргумент на користь послідовника на основі Ethereum.

як відзначено раніше, без сумніву, "вирівнювання" є продажем для початкових brs. це добре, але я не думаю, що це триватиме. круто бути першим br, не круто бути восьмим. потрібно мати ще якусь іншу додану вартість.

Я думаю, що надійний нейтралітет секвенсера на основі Ethereum потенційно є такою цінністю. Це, мабуть, найсильніший аргумент на користь такого дизайну. Є багато мереж, які хочуть отримати децентралізований секвенсор з полиці. Якщо ми врешті-решт зможемо розробити достатню інфраструктуру поверх цієї речі, щоб покращити крос-чейн UX, то ще краще. Я думаю, що серед проектів, які хочуть мати такий дизайн, багато з них не наважуються «вибрати чиюсь сторону» з будь-яким стороннім протоколом. Як зазначалося раніше, уявіть, що ви ланцюжок додатків з базовою загальною інфраструктурою, такою як ENS, і вам потрібен зведений пакет. Ви ж не хочете вибирати (гіпотетичний) секвенсор Arbitrum Shared і відключати натовп оптимістів, або навпаки.

Можливо, єдиним вирішенням проблеми соціальної координації тут є наявність достовірно нейтрального спільного секвенсора, на який Ethereum явно є найсильнішим кандидатом. Зауважте, що це робить ще більший акцент на пунктах, які я висловив раніше щодо надійного нейтралітету – якщо це основна додана вартість такої послуги, то це має бути неймовірно пріоритетною метою дизайну при її створенні. Він не спрацює, якщо має вигляд пет-проекту якогось стороннього протоколу зі своїми мотивами отримання прибутку. Насправді це має бути спільний секвенсор Ethereum.

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

швидкі роллапи на основі

швидкі базові шари

тепер ми повинні розуміти, що ви можете мати brs на повільному bl, як ethereum, ви можете додати довірені preconfs для швидшого ux, і навіть забезпечити безпеку при переході між ланцюжками за допомогою криптоекономічних або криптографічних гарантій.

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

раніше ми обговорювали, що єдиний технічний привід бути br з preconfs для певного bl (наприклад, ethereum) полягає в тому, щоб його пропонувач міг надавати вірогідні зобов'язання у певні моменти щодо синхронного атомарного включення з bl.

однак, ми не серйозно обговорювали можливість бути br без попередніх конфірмацій. Практично ми відкинули це, тому що ethereum повільний, а користувачі нетерплячі.

так чому ми просто не використовуємо швидкий bl для brs?

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

шарі умерли, нехай живуть послідовні шари!

більшість розмов щодо ледачих послідовників розглядає їх як послідовник rollup, який потім виводить свої дані на якийсь інший шар даних. Наприклад, перші два rollup Astria (ФормаіВогонь) використовуватиме Celestia як свій шар DA. Консенсус Astria секвенує ці зведення, а потім передає їхні дані Celestia.

ця комбінація особливо приємна, оскільки вони очевидно доповнюють один одного - astria надає всю інфраструктуру послідовності, а celestia забезпечує перевірку з мінімізацією довіри через вибіркове збирання даних про доступність (DAS).

однак астрию також можна використовувати для послідовності роллапу, що є властивим для Ethereum, Bitcoin, Solana або будь-чого іншого, що вам потрібно. Наприклад, його навіть можна налаштувати для використання як попередній конференц для Ethereum "brs з попередніми конференціями" (наприклад, замість централізованого Gate.ioway, як лінивий послідовник фактично просто стимулюваний та децентралізований реле).

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

однак, як я відзначив у Чи успадковують ролапи безпеку?, швидкі ланки, такі як astria, технічно могли б додати повільний шлях для das (для поліпшення перевірки), а повільні ланки, такі як celestia, могли б додати швидкий шлях для послідовності (з припущенням більшості довіри і без das), так звані “швидкі блоки повільні квадрати.”

Перехід до вертикальної інтеграції спеціалізованих рівнів, таких як послідовність або das, ще більше зменшить розрив між модульними та інтегрованими блокчейнами. Це також стосується вертикальної інтеграції шар розрахунківшляхом додаванняОблікові записи перевіряльника ZK на базовому рівні Celestia.

проте, збереження цих послуг окремо, а не у пакеті, має значну цінність. Це модульний підхід, який дозволяє роллапам вибирати, які функції вони хочуть отримати готовими (наприклад, я хочу купити децентралізовану послідовність зі швидкими блоками, але я не хочу платити за das, або навпаки). Дослідники показали, що вони хочуть das, але користувачі поки що показали, що вони просто хочуть швидких блоків.

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

швидкий базовий шар проти повільного + передконфігурацій

але ви також можете просто використовувати astria як bl для роллапів. спільні секвенціатори можна розглядати як bls, які оптимізовані для brs своїх власних.

Коли ваша бл швидка, вашому br не потрібні попередні підтвердження, оскільки він просто отримує швидкі підтвердження з коробки! Тоді ваш роллап дійсно отримує реальний часовий захист вашої бл, на відміну від brs + попередніх підтверджень, які обов'язково втрачають це.

brs без попередньої підтвердження фактично є найлогічнішим способом побудувати rollup. саме тому всі сучасні rollups почали з цього моменту:

Ясно, що блокчейн зі швидкими блоками вирішує більшість проблем у підході "базові ролапи + попередні конфігурації". Спільні послідовники будуються природніше з першопринципного підходу "розробники додатків просто хочуть запустити швидкий, надійний та децентралізований ланцюжок - як це зробити?" Спроба додати попередні конфігурації після того, як медленний базовий рівень, такий як Ethereum, вже існує, призводить до складностей, які ми описали вище.

ми всі будуємо одне й теж

модульність необхідна

Таким чином, ми побачили, як ми можемо об'єднати модульні ланцюги Gate.io разом, забезпечуючи універсальну синхронну композицію (usc). Звичайно, є певні компроміси, але вони повертають значну ступінь єдності, зберігаючи набагато більше гнучкості, ніж використання одного станового автомата. Також є дуже переконливий аргумент, що для великої більшості випадків використання ми потребуємо асинхронної композиції. Нам потрібна низька латентність, продуктивність і хороший UX. Інтернет є асинхронним і він досить добре абстрагує це все. Композиція - велика додана вартість криптовалюти, але композиція ≠ синхронія.

Незалежно від переваг гнучкості та суверенітету, більшість людей погоджуються з тим, що нам в кінці кінців знадобиться багато ланцюжків для масштабування. Це означає, що нам доведеться зіткнутися з багатьма системами, які нам потрібно об'єднати, тому модульний напрямок неминучий тут.

ethereum + preconfs → solana?

зараз порівняємо кінцівки тут. зокрема ми порівняємо кінцівку solana з кінцівкою ethereum, якщо вона піде цим шляхом максимізації єдності та користувацького досвіду з використанням rollups + preconfs.

у цьому баченні ми маємо низку цих brs, які використовують ethereum-базовий послідовник. Gate.io постійно транслює пропоновані-обіцяні (тобто без будь-якої ваги згоди) передваріанти користувачам з низькою задержкою, а потім пропонувальники ethereum затверджують їх у повний блок час від часу. це може звучати знайомо, оскільки це практично те, що ми описували раніше для solana зі shred streaming!

так, це просто більш складна версія solana? велика різниця тут полягає в часі слотів:

ethereum намагається додати це до повільного ланцюжка, що, на перший погляд, створює проблеми:

• консенсус Ethereum занадто повільний для користувачів, тому єдиний спосіб отримати нейтральний швидкий UX з гарантією від пропонента передбачених підтверджень за вибором користувача. Його основним обмеженням сьогодні є агрегація підписів через величезний набір перевірювачів (MaxEBі покращене агрегування підписів може допомогти тут).
• Це призводить до значно довших монополій пропозицій, забезпечуючи вищі стимули та свободу захоплення більшої кількості MEV, діючи недобросовісно (наприклад, утримуючи передоплати).
• якщо Gate.ioways почнуть затримувати або утримувати передконфігурації, то найгірший варіант для користувачів повертається до залежності від часів слотів Ethereum. навіть якщо виробники блоків Solana зупинили безперервну побудову блоків та потокове відтворення всередині їх виділених монополій (оскільки розумно припустити, що вони до певної міри роблять це з тієї самої причини) , тоді найгірший випадок повертається до покладення на швидко обертаючийся консенсус.Сьогодні потрібний монополіст з чотирма слотами для забезпечення надійності мережі.
• На практиці ймовірно буде надзвичайно мало шлюзів Gate.io, принаймні на початку, що призведе до більш централізованого набору операторів порівняно з ланцюжками, які, наприклад, Solana.
• потенційно надзвичайно високі вимоги до застави для пропонувачів (зауважуючи, що дизайн-простір все ще є предметом розробки).
• побоювання щодо проблем з живістю тут є надзвичайно коштовними (тому що проблеми з живістю оператора, що призводять до втрати попереднього підтвердження, є причиною порушень безпеки для користувачів, і тому повинні бути суттєво обмежені).

все це вирішується швидким консенсусом. усі ці системи буквально те, чому ми створюємо системи bft у першу чергу. Тому чому Ethereum не повинен робити свій консенсус швидшим? Чи є якісь менш очевидні компроміси з низькими базовими часами блоків?

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

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

джерело: Дані завжди

ігри на час були великою темою обговорення на дещо погано відомому Подкаст Джастина проти Толі без банківз кілька тижнів тому:

наприклад, давайте скажемо, ви на 100 мс швидше за всіх інших

якщо у вас є 1s слоти, ви можете заробити на 10% більше, ніж усі інші

якщо у вас є слоти на 10s, ви можете заробити на 1% більше, ніж усі інші

— Джон Шарбонно (@jon_charb)4 червня 2024 року

Джастін переважно стверджував, що гра в часі буде проблемою, і інкрементальні нагороди завжди будуть важливими. Толі переважно стверджував, що гра в часі не буде проблемою, і що інкрементальні нагороди, зароблені в результаті додаткової екстракції MEV, недостатньо важливі, щоб хвилюватися про них.

Особисто я вважаю важким ігнорувати важливість часу для ігор тут:

• ми вже бачимо їх на практиці сьогодні на Ethereum.Аргумент Solanaце трапляється лише тому, що mev став соціальною нормою в ефіріумі раніше, але це не переконливо, коли булосильний громадський протест проти зміни часу гри в ранній стадії що з того часу перетворилося на прийняттядля того, щоб проектувати нову реальність.
• нагороди mev є значними - ми вже говоримо промільярди доларів у платежах MEV тут, а не копійки під диванною подушкою. Навіть заробити на цьому «всього на кілька відсотків більше» – це величезні гроші.
• навіть якщо ви не вірите, що стейкери достатньо чутливі до доходів на межі,фактичні оператори ведуть бізнесі це безпосередньо впливає на їхню прибутковість.
• Солана легше покладатися на альтруїстичних великих зацікавлених сторін (наприклад, фонд і великі інвестори) на більш ранніх стадіях його життєвого циклу, але це нестійке, оскільки будь-яка мережа стає більш децентралізованою.

Я явно думаю, що в напрямку, в якому рухаються як Solana, так і Ethereum, є величезна цінність. У всякому разі, ми побачимо, як все це буде відбуватися на практиці. Зі стратегічної точки зору, я також вважаю, що для Ethereum має сенс спиратися на те, що відрізняє його від інших. максимізувати децентралізацію як засіб досягнення опору цензурі в умовах конкуренції. Ethereum пішов на багато жертв, щоб зберегти неймовірно децентралізований протокол, тому що це необхідність для довгої гри. Він має неперевершене різноманіття клієнтів, розподіл власності на мережу, зацікавлені сторони екосистеми, децентралізацію операторів тощо. Якщо (і, ймовірно, коли) Solana зіткнеться з серйозним тиском цензури в майбутньому, ставатиме все більш очевидним, чому Ethereum прийняв такі рішення.

Preconf.wtf щойно відбувся на Zuberlin минулого тижня, і, мабуть, не дивно, що всі говорили про preconf та базові ролапи. І це все було дуже круто. Але я особисто знайшов Доповідь Віталіканасписки включення одного біта на атестатораі промова БарнабіНатомість перевантажити пропозицію виконання (з mev-boost на epbs та aps)бути найважливішим для майбутнього Ethereum.

Target: Барнабе Монно, Від mev-boost до epbs до aps

Розмови про preconf і based rollup почали набирати обертів зовсім недавно, і я, безумовно, все ще дотримуюся більш обережної сторони. Віталік хвацько виклав наступне Кінець гри:

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

джерело: Доказ управління

емпірично, снабження ланки mev ethereum l1 в даний момент реального часу цензурує більше блоків, ніж будь-який з цих l2 з централізованими послідовниками.

L2 вже можуть отримати остаточний CR L1 (що все ще дуже добре) без базування. Засновані Preconf не отримують безпеку протоколу Ethereum у реальному часі, вони отримують безпеку в реальному часі невеликої жменьки відносно централізованих постачальників інфраструктури навколо нього. Для кращого CR у реальному часі найкращим варіантом, ймовірно, є передача секвенування на аутсорсинг якомусь типу децентралізованого секвенсора, що працює на простому консенсусі BFT. Це буде набагато надійніше, ніж централізація багатьох мереж у відносно централізоване вузьке місце. Ця ситуація може покращитися з такими змінами, як аукціони виконання та списки включення, але це не зовсім за горами.

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

висновок

ми всі будуємо одну й ту саму річ.

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

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

також, досить проклято неможливо мислити про деякі з цих речей.Як сказав Віталік:

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

Так само, як і з eip-1559, нам вдалося зрозуміти за допомогою теорії. Ми відвідали декілька чудових економічних конференцій і дізналися про небезпеки перших цінових аукціонів і те, як вони втомлюють, і зрозуміли, що другі цінові аукціони не є достовірними, а потім виявили, що, гей, давайте використовувати механізм, який є локалізованою фіксованою ціною в межах кожного блоку, і нам вдалося зробити багато з мікроекономікою.

але aps не такий, правда. і питання, чи приведе aps до цитаделі або джейн стріт або Джастіна Сана чи хтось інший до виробництва 1% всіх блоків Ethereum або 99%, дуже-дуже важко, ймовірно, неможливо визначити з першопринципів.

Так отже, те, що я хочу побачити на цей момент, - це живий експеримент... для мене особисто різниця між сьогоденням і тим, щоб я відчував себе дійсно дуже комфортно з APS, - це фактично успішна робота APS на Ethereum L2 з середньою кількістю вартості, активності, спільноти та реальних протиріч, що відбуваються, і це триває протягом року, можливо, навіть довше, та ми фактично можемо побачити деякі живі наслідки.

Так, я теж не знаю, що станеться. Нам доведеться просто зачекати й подивитися. В будь-якому випадку, поки ми всі збираємося до чогось, що буде наступним, у нас є багато спільного, тому давайте переконаймося, що...

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

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