20 000 слів: Дебати про безпеку Rollups

Спочатку написано Джоном Шарбонно Укладач Френк, Foresight News

Вступ

Подобається вам це чи ненависть, але Twitter, ймовірно, ніколи не перестане сперечатися про те, чи є «L2» або Rollup «успадковувати безпеку».

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

Чи усуває масштабований L2 потребу в L1 на ринку? Чи можна перетворити L1, такий як Solana, на L2?

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

Визначення модного слова

Згортання

Раніше я використовував наступне визначення Мустафи: «Rollup – це блокчейн, який публікує свої блоки в іншому блокчейні та успадковує консенсус і доступність даних (DA) цього блокчейну».

Нижче наведено більш загальне визначення, дане Джеймсом Прествічем: «Зведення — це спосіб підключитися до іншого механізму консенсусу шляхом налаштування функцій переходу станів і збереження стану надмножини».

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

Ми можемо розглянути такі критерії зведення:

• Rollup – це система зі збереженням стану (наприклад, блокчейн), отримана шляхом запуску спеціальної функції переходу станів (STF) на вхідних даних в основному ланцюжку (рівень DA).
• Усі вхідні дані (тобто повні дані про транзакції або різницю станів), які використовуються для отримання остаточного стану підтвердження віддаленого ланцюга (тобто зведення), підтверджуються в основному ланцюжку.
• Оскільки стан Rollup є похідним від функції переходу станів (STF), яка виконується на даних в основному ланцюжку, валідність Rollup залежить від валідності основного ланцюга. Потім вузол Rollup повинен повністю перевірити консенсус і валідність основного ланцюга (або зробити чесне припущення більшості про основний ланцюг);

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

Кросчейн-міст

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

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

• Традиційні кросчейн-мости зазвичай запускають легкі вузли валідатора консенсусу в ланцюжку (тобто те, чому вони довіряють більшості знаків консенсусу);
• Кросчейн-мости можуть забезпечити сильніші атрибути безпеки, діючи як повноцінні легкі вузли валідаторів (наприклад, додаючи вибірку доступності даних (DAS) + валідність/доказ відмови). Наприклад, валідатор ланцюга може потребувати запуску на всіх легких вузлах DAS, які з'єднують ланцюг, що є більш легкою альтернативою, ніж повний вузол, який вимагає від валідатора запуску підключеного ланцюга;
• Зведений кросчейн-міст також може зберігати активність і опір основного ланцюга (оскільки Rollup повинен розділяти консенсус основного ланцюга);

Перекриття від основного ланцюга → Rollup

Цей напрямок дуже простий, так як вузол Rollup повністю перевіряє основний ланцюжок.

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

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

• Блоки виконання Ethereum з підтвердженням валідності (дослідження zkEVM на базовому рівні тривають);
• Ethereum впровадив повну DAS, тому вузли можуть брати зразки DA;
• Виконавчий рівень Ethereum публікує свої дані у вигляді блобів на рівні даних, як і будь-який інший зведення на Ethereum (наприклад, дані виконавчого рівня Celestia будуть опубліковані на його рівні DA, тому вузли DAS перевірятимуть доступність даних Rollup і власного рівня виконання Celestia);
• Ethereum забезпечує повний доказ консенсусу замість того, щоб покладатися на комітети синхронізації (наприклад, за допомогою інтеграції валідаторів, кращої агрегації сигнатур, можливого доказу консенсусу ZK тощо);

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

• Консенсус Ethereum - будь-який клієнт легкої ноди може відстежувати консенсус, підписаний як блокчейн, заголовок блоку;
• Власний рівень виконання DA Ethereum – вузли зведення беруть зразки рівня DA Ethereum, перевіряючи доступність даних зведення та власних даних рівня виконання Ethereum (зверніть увагу, що вузли DAS все ще роблять деякі додаткові припущення щодо повних вузлів, як ми побачимо пізніше);
• Власна валідність стану Ethereum – з zkEVM кожен блок Ethereum поставляється з підтвердженням дійсності;

Вузли ролапу повинні перевіряти валідність стану та DA власного рівня виконання Ethereum, оскільки це умови валідності для блоків Ethereum. Вузол Rollup повинен знати, що він не тільки відстежує Ethereum, де було підписано консенсус, але й що це дійсний заголовок блоку. Наприклад, вони можуть випадково відстежувати блоки Ethereum, які підписані консенсусом, але недійсні (наприклад, він генерує багато ETH).

Якщо базовий рівень виконання сам публікує свої дані на рівні DA (так само, як і інші зведення) і додає валідність або доказ помилки, то він стає вбудованим зведенням.

Міст з основної мережі Rollup →

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

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

Зведення, співпроцесори та наміри

Як уже згадувалося, Rollups зберігають частину свого власного стану (стан Rollup) на додаток до того, що володіють станом свого основного ланцюга (наприклад, Ethereum). Отже, чи є у CoW Swap власний стан, який не є частиною стану Ethereum? Якщо так, то це звучить як згорток. Якщо ні, то це може бути «співпроцесор».

Однак навіть це питання не таке просте, як здається:

Натомість, можна подумати, що відмітним фактором є стійкість держави:

Якщо CoW Swap дозволяє конкретним учасникам надавати користувачам швидкі попередні підтвердження (швидше, ніж час блокування Ethereum) і обіцяє ордери, які включають пакети — оскільки пакетна обробка Ethereum займає більше часу, ніж хотілося б більшості користувачів, чи є тепер це зведенням?

Кріс Гоуз торкнувся цієї теми у своєму виступі на Саміті модульності, почавши з приблизного визначення намірів: «зобов'язання функції переваги для даного простору станів системи».

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

• Додатки на основі намірів – результуючі зміни стану вирішуються ончейн (наприклад, у прикладі CoW Swap застосунок знаходиться в базовому ланцюжку, тому там відбувається обмін токенами);
• Rollup application – використовує дані, надіслані в основний ланцюжок, для розрахунку змін стану, що генеруються Rollup;

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

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

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

У міру того, як перевірені офчейн-обчислення стають все більш важливими, межі між ними можуть стати розмитими:

Якщо ви хочете, щоб розв'язувачу намірів або зведеному замовленню довіряли менше...

Модульний блокчейн та монолітний блокчейн

Монолітні блокчейни (вони ж інтегровані блокчейни) часто визначаються як ланцюжки, які вертикально інтегрують усі основні функції, тобто консенсус, DA та виконання. Вони беруть на себе повну відповідальність за власну безпеку, і Solana та Cosmos Hub є яскравими прикладами.

Шари DA (такі як Ethereum і Celestia) часто називають «модульними» блокчейнами, оскільки вони передають виконання на аутсорсинг Rollup, але це не зовсім точно. Вони також несуть незалежну відповідальність за власний консенсус, DA та правозастосування.

Навіть виконання Celestia буде обмежене (наприклад, перекази, стейкінг, крос-чейн). Аналогічно, якщо хтось запустить Rollup поверх Solana, він не стане магічним чином «модульним» блокчейном.

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

Навіть Rollup не обов'язково є повністю «модульним» — секвенсер Rollup може домовитися про послідовність транзакцій, надати DA та виконати транзакції до того, як основний ланцюг щось зробить. Таким чином користувачі отримують попереднє підтвердження. Потім основний ланцюжок надає ще одне «остаточне» зобов'язання, знову оголошуючи DA та консенсус щодо порядку транзакцій Rollup.

Роллапи та інтегровані ланцюжки

Для наших цілей важливішою є відмінність "Rollup" або "Non-Rollup". Чи є остаточний стан ланцюга джерелом даних, опублікованих в окремому основному ланцюжку (тобто шарі DA)?

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

Віталік розповідає про цю різницю у своєму «Ендшпілі»:

Ви можете помітити, що «традиційний великий блокчейн» (інтеграційний ланцюжок) з DAS + валідністю/доказом невдачі може в кінцевому підсумку виглядати як «закріплений ролап»! Аналогічно, «масштабований і домінуючий ролап» може стати настільки успішним, що просто об'єднається зі своїм основним ланцюгом, щоб пристосуватися до цього зведення.

Межі відмінностей стають розмитими на межі.

Тому, якщо ви вважаєте, що ефективність DAS+/доказ невдачі є кінцевим результатом, то «Rollup» у певному сенсі неминучий. Між двома методами на попередній схемі є суттєва різниця:

• "Rollups" aka "модульність" - будують логічно незалежні ланцюжки, публікують дані в його основний ланцюжок (DA layer) і повторно використовують консенсус основного ланцюга;
• «Інтегрований блокчейн», він же «монолітний блокчейн» - інтегрувати все в один протокол з власним консенсусом, без публікації даних в окремий основний ланцюжок (навіть якщо рівень DA і рівень виконання є логічно окремими частинами спільного протоколу в певному сенсі);

Коли ми говоримо про "Rollup" у цьому звіті, ми маємо на увазі перший (тобто не інтеграційний ланцюжок з DAS + validity/proof of failure, який може називатися вбудованим Rollup).

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

Це вимагає фундаментального рефакторингу протоколу, щоб почати наближатися до того, що ми бачимо в Ethereum і Celestia:

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

З цієї причини ми бачимо, що команда будує наступне:

• Спеціалізовані шари DA (наприклад, Danksharding від Ethereum, Celestia і т.д.) - повільні блоки + DAS;
• Спільні секвенсори (наприклад, Espresso, Astria або навіть Solana) - насправді просто швидкі шари DA, DAS не потрібен;

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

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

Анатолій обговорює в подкасті, як Eclipse об'єднує Ethereum, Celestia та Solana, а з іншого кінця спектру ви можете уявити, як шар DA додає швидший шлях, перш ніж зробити дані доступними для вибірки:

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

Підтвердіть правило

З огляду на це, ми можемо почати розбирати атрибути безпеки цих різних архітектур.

По-перше, ноди взаємодіють з будь-яким блокчейном, виконуючи «правила підтвердження»:

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

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

• Скільки блоків потрібно почекати, перш ніж підтвердити транзакцію Bitcoin? 1 ？ 6 ？ 10 ？
• Ви використовуєте LMD GHOST для підтвердження блоків на основі реєстру Ethereum, що використовується, або чекаєте підтвердження останнього гаджета (Casper FFG)?
• Ви запускаєте повні ноди, які безпосередньо перевіряють кожен блок, чи лише легкі вузли, які перевіряють підписання консенсусу?
• Ви щойно запитали Інфуру?

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

Ця відмінність тонка, але важлива:

Безпека = Безпека + Активність

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

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

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

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

Використовуючи чудову структуру Sreeram, ми можемо розбити їх на п'ять атрибутів, які працюють разом, щоб забезпечити правила підтвердження:

Розглянемо приклад гіпотетичного інтеграційного ланцюжка з DAS + валідність/доказ відмови. Його дані не публікуються в жодному іншому зовнішньому основному ланцюжку. Для простоти ми припускаємо миттєве завершення (наприклад, Tendermint), тому немає корисної різниці між доступним реєстром і завершеним реєстром (наприклад, Gasper від Ethereum).

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

• Легкий вузол валідатора консенсусу - перевіряє доказ консенсусу (тобто довіряє чесному консенсусу більшості).
• Повний вузол валідатора - перевірити консенсус + перевірити DA (за допомогою DAS) + перевірити валідність стану (використовуючи валідність / доказ помилки);
• Повний вузол - верифікація консенсусу + пряма перевірка DA (завантаження всіх даних) і валідності (виконання всіх транзакцій і розрахунок статусу);

Підтвердьте, що правило має атрибути безпеки, ланцюжок не

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

Розглянемо кілька прикладів.

Теорема CAP

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

Адаптивність (вона ж динамічна доступність) - збереження активності з динамічною участю (тобто, якщо більшість вузлів знаходяться в автономному режимі); Finality (вона ж послідовність) – збереження безпеки під мережевими розділами;

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

• Протоколи з найдовшим ланцюгом - ці протоколи (наприклад, консенсус Сатоші Біткойна) гарантують активність, навіть якщо кількість активних вузлів, що беруть участь, є змінною (тобто вони адаптивні), однак вони не є безпечними (тобто не остаточними) при розбивці мережі; Протоколи типу BFT - Класичні протоколи консенсусу (наприклад, PBFT) досягають остаточності, але не досягають адаптивності;

Правила підтвердження Біткоіна

Консенсус біткойна не забезпечує жорсткої економічної остаточності.

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

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

Правила підтвердження Ethereum

Консенсус PoS Ethereum (Gasper), на перший погляд, здається обходом теореми CAP. Однак він реалізує ці дві властивості, оскільки містить два вкладені реєстри:

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

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

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

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

• Динамічно доступні правила - гарантована адаптивність. Поважайте заголовок блоку найдовшого ланцюга. LMD GHOST — правило вибору розгалуження, яке використовується для визначення найважчого піддерева;
• Правила фіналізації - гарантує остаточну визначеність. Поважайте блоки, підтверджені остаточними гаджетами. Casper FFG — це фінальні додатки, які застосовуються поверх правил вибору вилки;

Як обговорюється в статті:

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

Це дозволяє всім (чесним) вузлам системи:

• Дотримуйтесь загального механізму блокових пропозицій;
• Однак різні вузли можуть вибирати різні правила підтвердження;

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

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

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

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

Саме це пропонується в Ethereum Consensus Protocol Confirmation Rules, які пропонують правила підтвердження з наступними властивостями:

• В ідеальних умовах - правило буде підтверджувати новий блок відразу після його слота;
• У типових умовах основної мережі - правило повинно мати можливість підтвердити більшість нових блоків протягом хвилини;

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

Давайте розглянемо кілька прикладів, наприклад, якщо ви продаєте яхту за 2,5 мільйона доларів в ETH, ось кілька можливих правил підтвердження:

• Повна нода + очікування остаточного результату – навіть зловмисна більшість валідаторів не може обманом змусити вас прийняти недійсні блоки (наприклад, створити фальшиві ETH). Якщо вони заплатять вам 2,5 мільйона доларів ETH, а потім спробують реструктуризувати завершений блок пізніше, вони понесуть величезні витрати (принаймні третина капіталу карається скороченням);
• Повна нода + очікування блоку – більшість шкідливих валідаторів все ще не можуть обманом змусити вас прийняти недійсний блок, однак вони можуть відправити вам 2,5 мільйона доларів США в ETH в дійсному блоці, залишити на яхті, а потім блок негайно реорганізується, що можливо при достатній вазі ставки або поганих умовах мережі, вони не будуть карально скорочені;
• Light Node Client – Шкідливі плати синхронізації можуть збрехати вам без штрафу, і покупці можуть піти на яхті (зверніть увагу, що цей комітет синхронізації є ексклюзивним для Ethereum як підмножина консенсусу, інші ланцюжки PoS з більш ефективною підтримкою клієнтів легких вузлів можуть перевіряти всі голоси консенсусу з невеликою кількістю валідаторів);
• MetaMask – Ви просто довіряєте Infura, людина, яка купила у вас яхту, пообіцяла співробітнику Infura, що вони можуть забрати яхту на вихідних, тому вони збрехали вам, ви думали, що отримали 2,5 мільйона доларів в ETH, а потім ви передали ключі;

Rollup підтверджує правила

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

Типовий ланцюжок зведених транзакцій виглядає так:

• Користувач відправляє транзакцію секвенсеру;
• Секвенсор сортує транзакції та дає попереднє підтвердження;
• Детермінований STF слід застосовувати до впорядкованих транзакцій для обчислення нового стану зведення;
• Оновлені зобов'язання щодо статусу зведення та пов'язані з ним дані про транзакції нарешті передані в основний ланцюжок;

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

• Rollup Full Node - безпосередньо перевіряє правильність запропонованого стану ланцюжка;
• Легкі вузли rollup (включаючи мости перевірки) - не можуть бути перевірені безпосередньо;
• Різні спостерігачі одного і того ж Rollup використовують різні правила підтвердження, тому вони доопрацьовують свою точку зору в різний час:
• Припускають оприлюднення повних даних про транзакції (а не тільки відмінностей станів);
• Як згадувалося раніше, вузли Rollup також повинні запускати повні ноди основного ланцюга або повні легкі вузли валідатора (або використовувати легкі вузли валідаторів консенсусу, щоб зробити чесні припущення більшості). Легкі вузли зведення можуть запускатися як додаткове програмне забезпечення або неявно в межах основного вузла ланцюга (тобто зведення перевірки контрактів кросчейн-мосту в основному ланцюгу);

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

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

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

Ідея попереднього підтвердження добре вписується в логіку Гаспера, описану Віталіком:

Загальний принцип полягає в тому, що ви хочете надати користувачеві «якомога більше консенсусу»: якщо є > 2/3, то ми досягаємо консенсусу на регулярній основі, якщо ж < 2/3, то немає причин зволікати, нічого не надаючи, тому що, очевидно, ланцюжок продовжить зростати, незважаючи на тимчасово нижчий рівень безпеки нового блоку. Якщо одна програма не задовольняється нижчим рівнем безпеки, не соромтеся ігнорувати ці фрагменти, доки вони не будуть завершені.

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

Підтвердіть правило - безпека та доступність

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

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

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

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

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

Одним словом:

• Користувачі взаємодіють з будь-яким ланцюгом за допомогою правил підтвердження;
• Ланцюжок може мати будь-яку кількість правил підтвердження;
• Безпека - атрибут правила підтвердження, а не самого ланцюжка;
• Ми дбаємо про безпеку та доступність правил підтвердження для даного ланцюга;

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

Роллапи з інтеграційною безпекою ланцюжка

1 , ланцюжок інтеграції з доказом валідності DAS+

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

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

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

• Фактично недоступні дані;
• або допустимі переходи станів;

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

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

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

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

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

2, Proof of Rollup за допомогою DAS + валідність

Тепер давайте трохи змінимо цей приклад:

• Попередній приклад - ланцюжок інтеграції з доказом валідності DAS +, уявімо беремо сьогоднішню Solana, але додаємо доказ DAS +;
• Новий приклад - Rollup розгортається на зовнішньому основному ланцюжку (наприклад, Ethereum) з доказом валідності + DAS (зверніть увагу, що Ethereum DAS ще не працює), Rollup має децентралізований набір секвенсорів, який може досягати консенсусу зі швидким попереднім підтвердженням;

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

Fast Path - До консенсусу основного ланцюга

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

• Rollup Consensus Validator Light Node - довіряйте чесній більшості в консенсусі секвенсера Rollup;
• Rollup Full Validator Light Node - запускає DAS + на каналі секвенсера, щоб перевірити підтвердження валідності перед публікацією будь-чого в Ethereum;
• Rollup Full Node - завантажте всі дані з фіду секвенсера і виконуйте всі транзакції для безпосередньої перевірки DA і валідності;

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

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

• Покладайтеся на секвенсор Rollup для активності та боротьби з рекомбінацією, а не на набір валідаторів інтегрованого ланцюга;
• Видалено лише атрибут final activity, оскільки тут переглядається лише часовий діапазон до консенсусу основного ланцюга (ці атрибути «останньої» активності будуть самостійними пізніше в майбутньому);

Вилучення буде показано червоним закресленням, а додавання — синім:

Повільний шлях – дочекайтеся консенсусу основного ланцюга

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

• Легкий вузол валідатора консенсусу головного ланцюга - довіряйте чесному консенсусу більшості основного ланцюга;
• Повний валідатор основного ланцюга легкий вузол - перевірте доказ валідності основного ланцюга + запустіть DAS на основному ланцюжку (включаючи дані Rollup+ дані основного ланцюга);
• Повний вузол Mainchain - завантажте всі дані mainchain (включаючи перевірку даних зведення) + виконайте всі транзакції mainchain для безпосередньої перевірки дійсності;
• Зверніть увагу, що валідність стану Rollup можна перевірити двома різними шляхами:
• За межами основного ланцюга (з додатковим програмним забезпеченням вузла Rollup) - Rollup не вимагає від основного ланцюга перевірки його стану або STF, йому не потрібно розгортати міст перевірки, натомість він може перевірити доказ Rollup іншим методом (наприклад, отримання доказу Rollup через p2p), що вимагає запуску додаткового програмного забезпечення вузла Rollup для перевірки доказу (тобто легких вузлів Rollup);
• Усередині основного ланцюга (реалізувати вузол Rollup всередині основного ланцюга) - це норма на сьогоднішній день, логіка валідатора легкого вузла Rollup розгорнута в самому основному ланцюжку (тобто вбудований мостовий контракт Rollup), оскільки цей вузол валідатора Rollup працює всередині STF основного ланцюга, валідація STF основного ланцюга також означає перевірку STF зведення;

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

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

Нижче наведено відмінності в порівнянні з попередньою таблицею зведення Fast Path Rollup.

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

Роллап з інтегрованим блокчейном

Тепер ми можемо побачити зміни в атрибутах безпеки, пов'язаних з інтегрованим блокчейном і Rollup:

• Термін дії DA та штату - У разі впровадження підтвердження дійсності DAS+ може надати відповідні гарантії безпеки, незалежно від того, чи є ланцюг інтегрованим або традиційним Rollup. Фактично в цих технологіях сьогодні домінує Rollup; Стійкість до реорганізації – інтегровані блокчейни відповідають за це незалежно у всіх сценаріях. Натомість Rollup пропонує вибір правил підтвердження в різні часові проміжки. Ви можете використовувати менш безпечні правила підтвердження (консенсус секвенсера довіри), щоб отримати швидкі гарантії, або дочекатися більш безпечних правил підтвердження (дочекатися консенсусу мейнчейн);

Активність та резистентність до рекомбінації

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

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

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

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

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

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

• Антиреструктуризація – Rollup може делегувати антиреструктуризацію Ethereum, і його правила вибору форку ґрунтуються на тому, що підтверджує консенсус Ethereum для вибору «канонічного ланцюга». Якщо Ethereum реорганізується, Rollup також реорганізується.
• Жвавість – однак, якщо в Rollup відсутній механізм примусового включення та примусової заміни оператора, користувачі Rollup все одно не отримують атрибут жвавості Ethereum;

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

Це підкреслює важливість таких механізмів.

Доступність даних та термін дії статусу

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

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

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

• Зробіть DAS і доказ ефективності широко доступними;
• Якщо у вас немає DAS та/або підтвердження валідності, зробіть повні ноди широко доступними (тобто низькі вимоги до ресурсів, прості в запуску тощо);
• Якщо у вас немає DAS та/або доказу валідності, а повний вузол значною мірою недоступний, то, будь ласка, зробіть легкий вузол валідатора консенсусу широко доступним і майте надійний чесний консенсус більшості;
• Відвідайте Інфуру;

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

Повним нодам потрібно лише завантажити всі дані, тому вони впевнені на 100%. Підписують блок тільки тоді, коли все є. Жодних припущень щодо зовнішніх сторін не робилося.

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

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

Ці припущення «N-in-2» (наприклад, чесна меншість вузлів може забезпечити DAS) є дуже вигідними порівняно з типовим приблизним припущенням «N/2» (наприклад, 51% виробників блоків можуть призвести до реорганізації). Віталік добре розповів про це у своєму дописі про модель довіри.

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

Перегляньте приклад попередньої перевірки зведеного доказу:

• Опублікуйте доказ ZK у Rollup для смарт-контракту Ethereum, де ви запускаєте повну ноду Ethereum і неявно перевіряєте доказ;
• Надішліть ZK proof of Rollup на мій легкий вузол Rollup, щоб перевірити доказ безпосередньо;

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

Розглянемо шахрайський зведення на основі ланцюжка:

• Правила вибору форку Rollup слідують кінчику ланцюжка→ Якщо ланцюжок реорганізований, Rollup також реорганізується;
• Механізм обов'язкового включення та видалення секвенсера Rollup забезпечуються за допомогою міжланцюгових контрактів на шахрайському ланцюжку→ Якщо реєстр шахрайського ланцюга зупиняється, то зупиняється і реєстр зведення. Якщо шахрайська мережа хоче цензурувати ваш Rollup, то ви будете піддані цензурі;

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

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

Правильний вибір основного ланцюжка Rollup може мати конкретний вплив на атрибути безпеки. Особливо цінним є використання бекчейну з сильною активністю (зростання реєстру + CR) та опором реорганізації.

Різні припущення щодо безпеки для різних періодів часу

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

Роллап має такі характеристики:

• Час блоку 10 секунд;
• Підтримуються легкі вузли DAS
• Можуть бути надані правила підтвердження «високого рівня безпеки» для діяльності та антиреорганізації (наприклад, децентралізовані довірені валідатори тощо);

Інтегрований блокчейн має такі характеристики:

• Час виведення блоку - 1 секунда;
• Легкий вузол DAS і доказ валідності можуть бути реалізовані, незалежно від того, запускається він як інтегрований блокчейн або як ролап;
• Якщо реалізований централізований секвенсор - він забезпечить "низьку безпеку" правил підтвердження активності та стійкості до рекомбінації;
• Якщо він реалізує власний децентралізований консенсус (або як попередньо підтверджений набір секвенсерів Rollup, або як інтегрований набір валідаторів ланцюга), він надасть правила підтвердження «середнього рівня безпеки» для діяльності та антиреорганізації;

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

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

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

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

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

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

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

• Якщо baseline = операція всередині зведення, послідовне зведення L1 може забезпечити кращу активність. Нікому іншому в ланцюжку не можна обіцяти, поки основний ланцюг не буде підтверджений, тому ви всі в рівних умовах;
• Якщо baseline = операція поза Rollup - Rollup з м'якою попередньою кваліфікацією може забезпечити кращу активність. Попереднє підтвердження - це просто безкоштовна опція, і ви все одно повертаєтеся до основної гарантії ланцюга зі швидкістю основного ланцюга, але тим часом ви можете отримати слабшу гарантію. Якщо ви не довіряєте їм, просто дочекайтеся підтвердження основного ланцюга. Світ не зависає між блоками Ethereum, і для багатьох додатків застарілі ціни між тривалим часом блокування можуть бути неприйнятними;

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

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

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

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

Наприклад, якщо у користувача є надійний механізм примусового виходу або навіть примусового видалення оператора, то централізований секвенсер Rollup не може довільно стягувати з користувача орендну плату і блокувати її. Це загальна сфера, розглянута в доповіді Кріса Гоуса, присвяченій MEV: Conversion Cost Edge and Slow Gaming.

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

Proof не захищає ланцюжок, а захищає користувача

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

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

Щоб зрозуміти, чому важливо розрізняти поняття «доказ ланцюга» і «спостерігач ланцюга доказів», розглянемо наступне:

• Легкі вузли - легкі вузли згортання більш безпечні, якщо є докази, вони не повинні довіряти достовірності чиїхось слів;
• Full node - при наявності доказу безпека повного вузла Rollup не збільшиться і не зменшиться, ви можете запустити Rollup ( «песимістичний зведення») без вбудованого моста або навіть будь-якого доказу, якщо ви почнете відправляти доказ валідності, безпека повного вузла не збільшиться і не зменшиться;

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

Атестація захищає Rollup bridge

Верифікаційний міст Rollup є надзвичайно важливим спостерігачем! Докази дійсно гарантують безпеку мосту!

Як і у випадку з будь-яким типовим світловим вузлом, міст не може безпосередньо перевіряти валідність Rollup. Ми не віримо в чесну більшість, а захищаємо мости доказами. Протокол консенсусу для бази даних A (рівень DA) сортує хмари даних, а потім перевіряє, що міст незалежно перевіряє дійсність відповідного оновлення бази даних B (Rollup):

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

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

Розглянемо старий гіпотетичний сценарій щодо Terra:

• Terra має власний набір валідаторів, її нативний токен - LUNA, і можна випускати нативний UST;
• Osmosis має власний набір валідаторів, а його нативним токеном є OSMO.
• У нас є стандартний міст Terra ←→ Osmosis IBC, де кожна сторона запускає легкий вузол валідатора консенсусу іншого ланцюга (тобто кожна сторона мосту залежить від чесної більшості набору валідаторів іншого ланцюга);
• Ви запускаєте власну повну ноду для кожного ланцюга як користувач;
• Ми називаємо UST на осмосі, перекинутому через IBC, як osmoUST;
• Ми називаємо OSMO на Terra, з'єднаному через IBC, terraOSMO;
• Ви володієте terraOSMO на Terra;
• Ви робите LP в пулі osmoUST/OSMO на Osmosis;

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

• Карбувати підроблений UST → крос-чейн до Osmosis, щоб карбувати osmoUST, використовуйте його для виснаження всіх торгових пар osmoUST (наприклад, вилучити всі OSMO з пулу osmoUST/OSMO;
• Карбування підробленого terraOSMO → крос-чейн до осмосу, щоб вилучити всю нативну заставу OSMO, заблоковану на Osmosis, яка підтримує terraOSMO, усі terraOSMO, що залишилися на TerraOSMO, тепер більше не підтримуватимуться;
• Ну, тут не вистачає безпеки:
• Full node (me) - мій повний вузол розпізнає блоки Terra як недійсні та відхиляє їх, валідатори Terra не можуть вкрасти мої позиції terraOSMO або osmoUST/OSMO LP;
• Легкий вузол (міст) - міст просто перевіряє, чи підписаний консенсус Terra на блоці (не перевіряючи допустимі переходи станів), тому він не відхиляє їх, валідатори Terra можуть вкрасти заставу OSMO, що підтримує мій terraOSMO, і вивести всі OSMO з пулу osmoUST/OSMO (залишивши купу нікчемних osmoUST);

Міст використовує правила визнання з сильнішими припущеннями про довіру.

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

Зауважимо, що важливо, щоб ці несправності не «заражали» решту ланцюга, тобто несправність «заражала» активи Osmosis, які піддаються впливу мостового маршруту Terra, але в самому ланцюзі Osmosis немає помилки безпеки.

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

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

• Наразі зведення Ethereum вимагають, щоб їхні вузли запускали повні ноди Ethereum, і ці зведення поділяють консенсус Ethereum; Namada (окремий ланцюжок Tendermint, а не Rollup) вимагатиме від своїх вузлів запускати повні ноди Ethereum, однак Namada не погоджується з консенсусом Ethereum (тобто вона не публікує дані в Ethereum і не виводить свій стан на основі цього);

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

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

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

Це дуже схоже на те, як міст Rollup на Ethereum перевіряє докази Rollup, за винятком того, що він також може бути двонаправленим.

DA - Крім того, ланцюг може вимагати, щоб його вузли запускали легкі вузли DAS, які з'єднують ланцюг. Наприклад, ви можете мати два ланцюги Cosmos, які вимагають власних валідаторів для запуску легких вузлів DAS іншого ланцюга (якщо кожен ланцюг реалізує легкі клієнти DAS, які наразі не підтримуються). Як тільки це буде зроблено, кожен ланцюг тепер може знати валідність один одного та DA без необхідності запускати повні ноди.

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

Залежні та незалежні ланцюги

Давайте знову розглянемо наші п'ять атрибутів безпеки, тепер у контексті спостереження за мостом верифікації Rollup Rollup на Ethereum:

• Зростання реєстру – валідатори Ethereum можуть змусити реєстр Rollup продовжувати зростати (наприклад, транзакції примусового включення);
• Стійкість до цензури – валідатори Ethereum можуть змусити операторів Rollup не цензурувати на невизначений термін (наприклад, примусове включення транзакцій або заміна секвенсора);
• Антиреструктуризація – антиреструктуризація Rollup пов'язана з Ethereum. Якщо Ethereum реорганізується, то всі ролапи на Ethereum будуть перегруповані;
• Доступність даних - DA Rollup гарантовано, оскільки Rollup за визначенням походить від даних, підтверджених консенсусом основного ланцюга (де знаходиться контракт Rollup), Rollup і основний ланцюг поділяють консенсус злиття, DA є умовою валідності самого Ethereum, тому, якщо дані недоступні, то сам блок Ethereum недійсний. Міст може отримувати доступ до даних в основному ланцюжку без додавання припущень про довіру;
• Валідність стану - контракт перевірить підтвердження валідності переходу в стан Rollup (або дочекається проходження вікна виклику), яке доводить, що заявлене оновлення стану є валідним результатом застосування STF Rollup до відповідних даних, підтверджених в основному ланцюжку;

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

Віталік наводить корисний наочний приклад:

«Ви переводите 100 ETH на міст через Solana і отримуєте 100 Solana-WETH, а Ethereum отримує 51% атаки. Зловмисник вносить купу своїх ETH у Solana-WETH, а потім відновлює транзакцію на стороні Ethereum, як тільки сторона Solana підтвердить це. Контракт Solana-WETH більше не підтримується повністю, і, можливо, ваші 100 Solana-WETH тепер коштують лише 60 ETH. Навіть з ідеальним мостом на основі ZK-SNARK, який повністю підтверджує консенсус, він все ще вразливий до такої атаки 51%.

Тому завжди безпечніше зберігати нативні активи Ethereum на Ethereum або нативні активи Solana на Solana, ніж власні активи Ethereum на Solana або нативні активи Solana на Ethereum. У цьому контексті «Ethereum» відноситься не тільки до базового ланцюга, але і до будь-якого відповідного L2, побудованого на ньому.

Якщо Ethereum буде атакований на 51% і відновиться, Arbitrum і Optimism також відновляться, тому навіть якщо Ethereum атакує 51%, програми «cross-rollup», які зберігають стан на Arbitrum і Optimism, гарантовано залишаться незмінними. Якби Ethereum не був атакований на 51%, не було б можливості зробити атаку 51% на Arbitrum і Optimism відповідно. Таким чином, як і раніше, абсолютно безпечно зберігати активи, випущені компанією Optimism, що базується на Arbitrum.

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

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

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

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

• Залежність - віддалений ланцюг (тобто Rollup) поділяє консенсус основного ланцюга (тобто рівня DA) і отримує свій власний стан з даних на головному ланцюжку, віддалений ланцюг повинен зробити форк з основним ланцюгом і визначити його остаточність на основі основного ланцюга;
• Незалежні - Ці ланцюги мають власний незалежний консенсус, вони не виводять свій власний стан на основі даних про інші ланцюги. Вони не мають спільного зв'язку між віддаленим ланцюгом (наприклад, зведенням) ←→ основним ланцюгом (тобто рівнем DA). Вони не перегруповуються разом і не залежать від активності один одного;
• Цікаво, що це і добре, і погано:
• Погано - Реорганізація вашого ланцюга з іншими ланцюгами або збої в активності можуть здатися недоліком на перший погляд, чому мій ланцюг має проблеми, тому що ваш ланцюг розірваний?
• Добре - якщо ця розбіжність спричиняє серйозні проблеми у вашому ланцюжку, це насправді важлива перевага (наприклад, якщо у вас є велика кількість кросчейн-активів із вихідного ланцюга, то він буде реорганізований з точки зору вашого кросчейн-мосту, залишаючи незабезпечену заставу), ланцюг та його кросчейн-міст повинні бути узгоджені один з одним;

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

• Добре - хороший мейнчейн захищає користувачів Rollup від операторів Rollup, які вичавлюють з них занадто багато цінності, примусово вимагаючи привілеїв виходу;
• Погано - Погані бекчейни можуть довільно завищувати ціну та отримувати це значення від Rollup та його користувачів;
• Підтвердження подання + запуск DAS в обох напрямках замість спільного використання загального основного ланцюга також має деякі недоліки:
• Ви не хочете вимагати, щоб ваш вузол запускав купу легких вузлів DAS інших ланцюгів, і вам доведеться вручну додавати нові ланцюги, запуск DAS на величезному спільному рівні DA набагато ефективніший;
• Для кожного ланцюга неефективно перевіряти валідність для багатьох різних ланцюгів, однак теоретично можливо агрегувати докази між кількома ланцюгами так, що весь ланцюговий кластер повинен опублікувати лише один доказ у ланцюжку;

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

Висновок

"Rollups inheritance security" - це хороша скорочення, але пам'ятайте, що це ключові моменти, які ми насправді маємо на увазі:

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

Тепер розглянемо переваги розгортання Rollup у ланцюжку інтеграції:

Безпека користувачів – незалежно від того, чи хочете ви впровадити будь-які кросчейн-мости чи ні, Rollups може орендувати DA у свого основного ланцюга та відновити його консенсус, що дозволяє Rollup надавати користувачам правила підтвердження, які відповідають основному ланцюгу, без необхідності досягати власного консенсусу;

Крос-чейн безпека - Rollup може створювати крос-чейн в рамках спільного домену безпеки основного ланцюга (тобто самого основного ланцюга та його Rollup), а його властивості безпеки можна порівняти з роботою в самому основному ланцюжку;

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

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

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

Однак сьогодні в цих технологіях верифікації та масштабування явно домінують рівні «традиційного зведення» та DA.