На додаток до добре відомих методів класифікації Validity Rollup і Optimistic Rollup?
Автор: NIC Lin
Попередні знання:
Зрозумійте, як працює Rollup і проблема доступності даних (Data Availability) Rollup
Резюме зведення
Незалежно від того, чи це Validity Rollup чи Optimistic Rollup, вони завантажуватимуть дані в L1 (наприклад, Ethereum), щоб кожен міг отримати доступ до даних зведеного пакету, отримавши доступ до L1, і використовувати це для отримання останнього статусу Rollup, наприклад У Аліси 10 USDT, а у Боба 5 USDT.
Ті, які не завантажують дані в L1, не належать до Rollup (наприклад, Validium, zkPorter або Arbitrum AnyTrust), і вони не є об’єктом цієї статті. Крім того, у цій статті не обговорюватиметься, як Rollup перевіряє дійсність стану, тобто різниця між Validity Rollup і Optimistic Rollup.
У першій частині цієї статті буде представлено Sovereign Rollup. Sovereign Rollup, як випливає з назви, є зведеним пакетом з автономією. Оновлення версій зведеного пакета або хард-форки відбуваються на Sovereign Rollups, на відміну від зведених пакетів, з якими зараз усі знайомі (надалі іменуються класичними зведеними пакетами). Розташування форка: не на Classic Rollup, а на контракті L1 Rollup: контракт L1 Rollup виконує оновлення версій через гаманці з кількома підписами або голосування за управління. Тобто контракт на L1 визначає, яку версію має використовувати зведене оновлення. І якщо відбувається атака на зведений пакет на рівні L1, наприклад атака на механізм управління або атака на сам контракт зведеного пакету, це вплине на зведений пакет. Навпаки, оскільки Sovereign Rollup просто розглядає L1 як місце для зберігання даних, усі учасники Sovereign Rollup можуть вирішувати, яку версію використовувати в поточному ланцюжку, і незалежно від того, що станеться з L1, якщо сам L1 не піддається атаці (наприклад, як Re-org або завершення ланцюга), Суверенний зведений пакет не вплине.
У другій частині буде представлено Based Rollup. Based Rollup усуває такі ролі, як Sequencer, і передає повноваження сортування транзакцій майнерам рівня 1, валідаторам, шукачам MEV тощо. Це не тільки робить сортування транзакцій більш децентралізованим, але також спрощує дизайн і видаляє багато компонентів системи.
Суверенний зведений пакет
Рівень доступності даних і рівень розрахунків
Класичний зведений пакет, такий як Arbitrum, Optimism, StarkNet тощо, не лише розглядає Ethereum (L1) як місце для зберігання даних (тобто рівня доступності даних), але також розглядає Ethereum як рівень розрахунків одночасно: розрахунок є виконується на Ethereum, а стан L2 (тобто баланс кожної адреси в L2) записується в L1.
Чому вам потрібно записати стан L2 у L1? Оскільки таким чином L2 і L1 можуть обмінюватися інформацією та активами: dApps L1/L2 можуть синхронізувати інформацію та співпрацювати, ETH L1 можна безпечно передавати між L1/L2, а ARB/OP L2 також можна безпечно передавати між L1/L2. передача між L2.
L1 може читати статус L2 і може безпечно передавати повідомлення, а L1/L2 можуть спілкуватися один з одним
Суверенний зведений пакет видаляє рівень розрахунків (або перетворює себе на рівень розрахунків) і просто використовує L1 як рівень доступності даних.
L1 лише зчитує дані блоку або транзакції, які Sovereign Rollup поміщає в L1, але не знає останнього статусу L2, тому немає можливості зв’язатися
Навіщо видаляти розрахунковий шар? Є різні підстави або причини:
Як згадувалося на початку, якщо рівень розрахунків Rollup знаходиться в L1, на нього впливатиме L1, незалежно від того, буде він оновлений чи атакуваний
Можливо, L1 сам по собі не підтримує складні обчислення для запису стану Rollup і використання цього стану для передачі інформаційних ресурсів. Наприклад, на Celestia ви можете лише просто розміщувати дані, а на Bitcoin ви можете. Він може лише виконувати обчислення з обмеженими можливостями, і такий L1 не може стати рівнем розрахунків
Можливо, для самого Rollup не потрібен інший ланцюжок, як для Settlement Layer, він має власні токени та екологію, і йому не потрібно обмінюватися активами з L1
Як працює суверенний зведений пакет
Sovereign Rollup просто використовує L1 як рівень доступності даних, завантажує дані на L1 і покладається на L1, щоб гарантувати, що дані доступні та порядок даних не змінюється. Вузли суверенного зведення покладаються на зчитування та інтерпретацію даних на L1 для обчислення останнього стану суверенного зведення. «Інтерпретація та обчислення» фактично представляють правила консенсусу Sovereign Rollup і функцію переходу стану: як відфільтрувати блоки та транзакції, які відповідають формату та правилам Sovereign Rollup, із даних L1, як перевірити ці блоки та транзакції після скринінгу та перевірити, як потім виконати ці транзакції, щоб обчислити останній стан.
Вузол Sovereign Rollup відсіює власні блоки з даних L1, інтерпретує та обчислює останній статус
Якщо два вузли Sovereign Rollup мають різні версії, вони можуть інтерпретувати різні дані або обчислювати різні останні стани, і, отже, ці два вузли не будуть в одному ланцюжку, вони бачать один із двох роздвоєних ланцюжків.
Різні версії вузлів можуть отримувати різні статуси, і вони розгалужуються на різні ланцюги *
Це фактично те саме, що запуск різних версій вузлів Ethereum, дві версії можуть не бути однаковим ланцюжком. Наприклад, після хардфорка ті, хто забули оновити версію вузла або не бажають оновлювати версію вузла, природно, залишаться в оригінальному ланцюжку (наприклад, ETC, ETHPoW), тоді як ті, хто оновить версію вузла, будуть на новий ланцюг (ETH).
Читачі тут також повинні знати, чому це називається Sovereign Rollup, оскільки в Sovereign Rollup кожен може вибрати версію вузла та інтерпретувати дані відповідно до (соціального) консенсусу своєї власної групи. Якщо сьогодні в спільноті Sovereign Rollup є розбіжності, як-от ETHPoW проти ETH, це означає, що кожен йде своїм шляхом і обирає різні версії вузлів для інтерпретації даних, але дані залишаються оригінальними та не змінюються.
*Примітка: звичайно, після розгалуження вузли відповідних версій завантажуватимуть дані, які відповідають їхнім власним правилам, у L1, а потім обидві сторони безпосередньо відфільтровуватимуть дані, завантажені іншою стороною. *
У середній момент часу наступні вузли розгалужуються до версії v1.1.2, а потім блоки один одного стали незалежними
Які суверенні зведені програми існують?
Наразі немає прикладів Sovereign Rollups, але оскільки тенденція модульного дизайну блокчейна стає все більш і більш популярною, безперечно буде багато Sovereign Rollups. Наприклад, модульний фреймворк Rollkit, який розробляє Celestia, може створити суверенний зведений пакет через Cosmos SDK. На відміну від оригінального ланцюга (L1), створеного з використанням Cosmos SDK, який потребує впровадження консенсусу Tendermint для визначення порядку транзакцій, Sovereign Rollup може використовувати єдиний Sequencer для сортування транзакцій, як поточний загальний Rollup, усуваючи потребу в кількох консенсусах. вузлів і покладаючись на його проблеми безпеки та ресурси, спожиті для виконання алгоритму консенсусу. А Sovereign Rollup завантажує дані транзакцій до Celestia, але в той же час, оскільки це Sovereign Rollup, на нього не вплине L1 (наприклад, оновлення або атака).
*Примітка 1: Пізніше Rollkit також підтримував використання біткойна як рівня доступності даних. Таке зведення може успадкувати безпеку біткойна, але пропускна здатність буде обмежена біткойнами. *
*Примітка 2. Загалом ланцюжки на основі Celestia можна назвати Sovereign Rollup. *
Або припустімо, що Arbitrum більше не використовує Ethereum як рівень розрахунків, більше не потребує обміну інформацією чи активами з Ethereum і просто розглядає Ethereum як місце для зберігання даних, тоді такий Arbitrum також стане суверенним зведеним пакетом.
Зведення розрахунків
Існують також такі визначення, як Settlement Rollup, але це в основному Sovereign Rollup, і тоді цей Sovereign Rollup також буде рівнем розрахунків інших ланцюжків. Тобто, якщо в суверенному зведеному пакеті є інші ланцюги, а інші зведені вважають його рівнем розрахунків, цей суверенний зведений пакет можна назвати зведеним розрахунком.
*Примітка: щоб мати можливість стати розрахунковим рівнем інших мереж, він повинен мати основні функції смарт-контракту, щоб дві сторони могли обмінюватися інформацією та активами. *
Якщо Ethereum буде змінено для завантаження всієї інформації про ланцюги в Celestia сьогодні, тоді такий Ethereum буде суверенним зведенням на Celestia, а також це буде зведенням розрахунків, оскільки в Ethereum є багато ланцюжків, і багато зведених розглядають його як рівень розрахунків .
Ethereum — це суверенний зведений пакет на Celestia, а також зведений розрахунковий пакет
Примітка. Можливо, у майбутньому всі поступово ознайомляться з модульністю та функціями різних рівнів і більше не будуть починати з точки зору Rollup, а такі терміни, як Sovereign Rollup або Settlement Rollup, поступово зникнуть. У будь-якому випадку, важливим є те, як спроектувати свій ланцюг (незалежно від того, чи це L1, L2, L3 тощо), як знайти компроміси та вибрати відповідні інструменти для будівництва для різних рівнів.
На основі зведення
Ще одна нещодавно з’явилася класифікація зведених пакетів – Based Rollup, або відома як L1-sequenced Rollup. Based Rollup Based відноситься до сортування транзакцій. Зведений пакет не передається секвенсору (або кільком секвенсорам) для сортування транзакцій, а повністю передається майнерам L1, валідаторам або пошуковцям MEV тощо для сортування транзакцій. Коли Classic Rollup завантажує дані в L1, контракт L1 Rollup перевіряє, чи їх завантажив кваліфікований Sequencer, тоді як Based Rollup не має обмежень, і кожен може завантажити їх.
Будь-хто може завантажувати Blocks of Based Rollup
Найбільша перевага Based Rollup полягає в тому, що немає Sequencer, тому немає єдиної точки відмови або навіть необхідності турбуватися про те, що Sequencer має повну силу впорядкування транзакцій, тобто немає необхідності турбуватися про збій Sequencer і спричинення відключення ланцюга. або навмисне неприйняття транзакцій від конкретних користувачів, або хвилювання, що секвенсор зловмисно захопить MEV користувача. Based Rollup повністю успадковує ступінь децентралізації L1 у генерації блоків.
Based Rollup має такі переваги:
Вартість виходу користувачів з Rollup дуже низька
Як правило, Rollup розробляє механізм примусового включення або механізм Escape Hatch, щоб користувачі могли безпосередньо інсталювати себе в L1 без використання Sequencer, щоб запобігти навмисному неприйняттю певних транзакцій користувача Sequencer або збоям Sequencer, які не дозволяють користувачам вийти з Rollup. Блок L2. Однак, перша ціна такого дизайну — це висока вартість. Користувачі повинні платити комісію майнеру L1, щоб вставити транзакції. Друга ціна полягає в тому, що транзакції, вставлені з L1, можуть вплинути на процес упаковки секвенсором блоків L2: цілком можливо, що L1 буде вставити Транзакція зробить недійсною транзакцію, яку секвенсор має намір зібрати в блок L2. Наприклад, транзакція, вставлена Алісою в L1, передає всі гроші Бобу, що призводить до невдачі транзакції, в якій Аліса переказує гроші Керол у блок L2.
Після отримання транзакції Аліси Sequencer підтверджує результат транзакції та поміщає його в наступний блок
Але Аліса надсилає іншу транзакцію безпосередньо до рівня L1 через примусове включення, що призводить до помилки транзакції Аліси, отриманої секвенсором
Щоб транзакція, вставлена L1, не вплинула на процес упаковки секвенсором блоків L2, Arbitrum не набуде чинності негайно, коли транзакція, вставлена L1, потребує очікування, поки секвенсор активно подає заявку на включення транзакції в останній блок перед він почне діяти, або, якщо секвенсор не відповідає, почне діяти через деякий час. Оптимізм дозволяє транзакції негайно вступити в силу. Якщо транзакція, вставлена L1, впливає на транзакцію в блоці L2, Sequencer повинен знайти спосіб впоратися з нею. Ви можете прочитати цей вступ, щоб дізнатися більше про порівняння між Arbitrum і Optimism під час обробки транзакцій розміщення L1.
Набагато простіший дизайн
Based Rollup має меншу роль Sequencer, ніж загальний Rollup, що означає менше навантаження на апаратне забезпечення (не потрібно турбуватися про завантаження машини Sequencer) і будь-який механізм, щоб зробити транзакції впорядкування більш справедливими (наприклад, механізм децентралізованого Sequencer). Тоді немає потреби в механізмі Force Inclusion/Escape Hatch, включаючи пов’язані з L1 контракти та пов’язані інструменти поза ланцюгом, щоб полегшити користувачам самостійно розміщувати транзакції в L1.
Але Based Rollup також має деякі недоліки:
Немає послуги підтвердження транзакції заздалегідь
За допомогою Sequencer Sequencer може швидко повідомити користувачеві результат виконання його транзакції. Поки користувач довіряє секвенсору, результат транзакції можна підтвердити негайно, не чекаючи, поки транзакція буде завантажена в L1.
У Based Rollup Аліса чекає, поки транзакцію буде завантажено в L1, перш ніж вона повірить, що її транзакцію включено, і їй потрібно дочекатися принаймні одного блоку L1
У загальному зведенні, якщо Аліса вважає, що секвенсор прийме її транзакцію, вона може негайно підтвердити, чи буде транзакція прийнята
Протокол втрачає джерело доходу від MEV
MEV більше не передається секвенсеру для перевірки та вилучення, а L1, тому сам L2 не має можливості отримати переваги MEV. Дохід від MEV можна отримати, розробивши механізм торгів для прав на виробництво блоків, але це відносно збільшить поріг для учасників L1 для участі у виробництві блоків, що зменшить ступінь децентралізації, а запровадження механізму торгів також принесе певного ступеня складності.
Посилання та рекомендована додаткова література
Sovereign Rollup
На основі зведення
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Одна стаття, щоб зрозуміти класифікацію Rollup
Автор: NIC Lin
Попередні знання:
Зрозумійте, як працює Rollup і проблема доступності даних (Data Availability) Rollup
Резюме зведення
Незалежно від того, чи це Validity Rollup чи Optimistic Rollup, вони завантажуватимуть дані в L1 (наприклад, Ethereum), щоб кожен міг отримати доступ до даних зведеного пакету, отримавши доступ до L1, і використовувати це для отримання останнього статусу Rollup, наприклад У Аліси 10 USDT, а у Боба 5 USDT.
Ті, які не завантажують дані в L1, не належать до Rollup (наприклад, Validium, zkPorter або Arbitrum AnyTrust), і вони не є об’єктом цієї статті. Крім того, у цій статті не обговорюватиметься, як Rollup перевіряє дійсність стану, тобто різниця між Validity Rollup і Optimistic Rollup.
У першій частині цієї статті буде представлено Sovereign Rollup. Sovereign Rollup, як випливає з назви, є зведеним пакетом з автономією. Оновлення версій зведеного пакета або хард-форки відбуваються на Sovereign Rollups, на відміну від зведених пакетів, з якими зараз усі знайомі (надалі іменуються класичними зведеними пакетами). Розташування форка: не на Classic Rollup, а на контракті L1 Rollup: контракт L1 Rollup виконує оновлення версій через гаманці з кількома підписами або голосування за управління. Тобто контракт на L1 визначає, яку версію має використовувати зведене оновлення. І якщо відбувається атака на зведений пакет на рівні L1, наприклад атака на механізм управління або атака на сам контракт зведеного пакету, це вплине на зведений пакет. Навпаки, оскільки Sovereign Rollup просто розглядає L1 як місце для зберігання даних, усі учасники Sovereign Rollup можуть вирішувати, яку версію використовувати в поточному ланцюжку, і незалежно від того, що станеться з L1, якщо сам L1 не піддається атаці (наприклад, як Re-org або завершення ланцюга), Суверенний зведений пакет не вплине.
У другій частині буде представлено Based Rollup. Based Rollup усуває такі ролі, як Sequencer, і передає повноваження сортування транзакцій майнерам рівня 1, валідаторам, шукачам MEV тощо. Це не тільки робить сортування транзакцій більш децентралізованим, але також спрощує дизайн і видаляє багато компонентів системи.
Суверенний зведений пакет
Рівень доступності даних і рівень розрахунків
Класичний зведений пакет, такий як Arbitrum, Optimism, StarkNet тощо, не лише розглядає Ethereum (L1) як місце для зберігання даних (тобто рівня доступності даних), але також розглядає Ethereum як рівень розрахунків одночасно: розрахунок є виконується на Ethereum, а стан L2 (тобто баланс кожної адреси в L2) записується в L1.
Чому вам потрібно записати стан L2 у L1? Оскільки таким чином L2 і L1 можуть обмінюватися інформацією та активами: dApps L1/L2 можуть синхронізувати інформацію та співпрацювати, ETH L1 можна безпечно передавати між L1/L2, а ARB/OP L2 також можна безпечно передавати між L1/L2. передача між L2.
L1 може читати статус L2 і може безпечно передавати повідомлення, а L1/L2 можуть спілкуватися один з одним
Суверенний зведений пакет видаляє рівень розрахунків (або перетворює себе на рівень розрахунків) і просто використовує L1 як рівень доступності даних.
L1 лише зчитує дані блоку або транзакції, які Sovereign Rollup поміщає в L1, але не знає останнього статусу L2, тому немає можливості зв’язатися
Навіщо видаляти розрахунковий шар? Є різні підстави або причини:
Як працює суверенний зведений пакет
Sovereign Rollup просто використовує L1 як рівень доступності даних, завантажує дані на L1 і покладається на L1, щоб гарантувати, що дані доступні та порядок даних не змінюється. Вузли суверенного зведення покладаються на зчитування та інтерпретацію даних на L1 для обчислення останнього стану суверенного зведення. «Інтерпретація та обчислення» фактично представляють правила консенсусу Sovereign Rollup і функцію переходу стану: як відфільтрувати блоки та транзакції, які відповідають формату та правилам Sovereign Rollup, із даних L1, як перевірити ці блоки та транзакції після скринінгу та перевірити, як потім виконати ці транзакції, щоб обчислити останній стан.
Вузол Sovereign Rollup відсіює власні блоки з даних L1, інтерпретує та обчислює останній статус
Якщо два вузли Sovereign Rollup мають різні версії, вони можуть інтерпретувати різні дані або обчислювати різні останні стани, і, отже, ці два вузли не будуть в одному ланцюжку, вони бачать один із двох роздвоєних ланцюжків.
Це фактично те саме, що запуск різних версій вузлів Ethereum, дві версії можуть не бути однаковим ланцюжком. Наприклад, після хардфорка ті, хто забули оновити версію вузла або не бажають оновлювати версію вузла, природно, залишаться в оригінальному ланцюжку (наприклад, ETC, ETHPoW), тоді як ті, хто оновить версію вузла, будуть на новий ланцюг (ETH).
Читачі тут також повинні знати, чому це називається Sovereign Rollup, оскільки в Sovereign Rollup кожен може вибрати версію вузла та інтерпретувати дані відповідно до (соціального) консенсусу своєї власної групи. Якщо сьогодні в спільноті Sovereign Rollup є розбіжності, як-от ETHPoW проти ETH, це означає, що кожен йде своїм шляхом і обирає різні версії вузлів для інтерпретації даних, але дані залишаються оригінальними та не змінюються.
*Примітка: звичайно, після розгалуження вузли відповідних версій завантажуватимуть дані, які відповідають їхнім власним правилам, у L1, а потім обидві сторони безпосередньо відфільтровуватимуть дані, завантажені іншою стороною. *
У середній момент часу наступні вузли розгалужуються до версії v1.1.2, а потім блоки один одного стали незалежними
Які суверенні зведені програми існують?
Наразі немає прикладів Sovereign Rollups, але оскільки тенденція модульного дизайну блокчейна стає все більш і більш популярною, безперечно буде багато Sovereign Rollups. Наприклад, модульний фреймворк Rollkit, який розробляє Celestia, може створити суверенний зведений пакет через Cosmos SDK. На відміну від оригінального ланцюга (L1), створеного з використанням Cosmos SDK, який потребує впровадження консенсусу Tendermint для визначення порядку транзакцій, Sovereign Rollup може використовувати єдиний Sequencer для сортування транзакцій, як поточний загальний Rollup, усуваючи потребу в кількох консенсусах. вузлів і покладаючись на його проблеми безпеки та ресурси, спожиті для виконання алгоритму консенсусу. А Sovereign Rollup завантажує дані транзакцій до Celestia, але в той же час, оскільки це Sovereign Rollup, на нього не вплине L1 (наприклад, оновлення або атака).
*Примітка 1: Пізніше Rollkit також підтримував використання біткойна як рівня доступності даних. Таке зведення може успадкувати безпеку біткойна, але пропускна здатність буде обмежена біткойнами. *
*Примітка 2. Загалом ланцюжки на основі Celestia можна назвати Sovereign Rollup. *
Або припустімо, що Arbitrum більше не використовує Ethereum як рівень розрахунків, більше не потребує обміну інформацією чи активами з Ethereum і просто розглядає Ethereum як місце для зберігання даних, тоді такий Arbitrum також стане суверенним зведеним пакетом.
Зведення розрахунків
Існують також такі визначення, як Settlement Rollup, але це в основному Sovereign Rollup, і тоді цей Sovereign Rollup також буде рівнем розрахунків інших ланцюжків. Тобто, якщо в суверенному зведеному пакеті є інші ланцюги, а інші зведені вважають його рівнем розрахунків, цей суверенний зведений пакет можна назвати зведеним розрахунком.
*Примітка: щоб мати можливість стати розрахунковим рівнем інших мереж, він повинен мати основні функції смарт-контракту, щоб дві сторони могли обмінюватися інформацією та активами. *
Якщо Ethereum буде змінено для завантаження всієї інформації про ланцюги в Celestia сьогодні, тоді такий Ethereum буде суверенним зведенням на Celestia, а також це буде зведенням розрахунків, оскільки в Ethereum є багато ланцюжків, і багато зведених розглядають його як рівень розрахунків .
Ethereum — це суверенний зведений пакет на Celestia, а також зведений розрахунковий пакет
Примітка. Можливо, у майбутньому всі поступово ознайомляться з модульністю та функціями різних рівнів і більше не будуть починати з точки зору Rollup, а такі терміни, як Sovereign Rollup або Settlement Rollup, поступово зникнуть. У будь-якому випадку, важливим є те, як спроектувати свій ланцюг (незалежно від того, чи це L1, L2, L3 тощо), як знайти компроміси та вибрати відповідні інструменти для будівництва для різних рівнів.
На основі зведення
Ще одна нещодавно з’явилася класифікація зведених пакетів – Based Rollup, або відома як L1-sequenced Rollup. Based Rollup Based відноситься до сортування транзакцій. Зведений пакет не передається секвенсору (або кільком секвенсорам) для сортування транзакцій, а повністю передається майнерам L1, валідаторам або пошуковцям MEV тощо для сортування транзакцій. Коли Classic Rollup завантажує дані в L1, контракт L1 Rollup перевіряє, чи їх завантажив кваліфікований Sequencer, тоді як Based Rollup не має обмежень, і кожен може завантажити їх.
Будь-хто може завантажувати Blocks of Based Rollup
Найбільша перевага Based Rollup полягає в тому, що немає Sequencer, тому немає єдиної точки відмови або навіть необхідності турбуватися про те, що Sequencer має повну силу впорядкування транзакцій, тобто немає необхідності турбуватися про збій Sequencer і спричинення відключення ланцюга. або навмисне неприйняття транзакцій від конкретних користувачів, або хвилювання, що секвенсор зловмисно захопить MEV користувача. Based Rollup повністю успадковує ступінь децентралізації L1 у генерації блоків.
Based Rollup має такі переваги:
Вартість виходу користувачів з Rollup дуже низька
Як правило, Rollup розробляє механізм примусового включення або механізм Escape Hatch, щоб користувачі могли безпосередньо інсталювати себе в L1 без використання Sequencer, щоб запобігти навмисному неприйняттю певних транзакцій користувача Sequencer або збоям Sequencer, які не дозволяють користувачам вийти з Rollup. Блок L2. Однак, перша ціна такого дизайну — це висока вартість. Користувачі повинні платити комісію майнеру L1, щоб вставити транзакції. Друга ціна полягає в тому, що транзакції, вставлені з L1, можуть вплинути на процес упаковки секвенсором блоків L2: цілком можливо, що L1 буде вставити Транзакція зробить недійсною транзакцію, яку секвенсор має намір зібрати в блок L2. Наприклад, транзакція, вставлена Алісою в L1, передає всі гроші Бобу, що призводить до невдачі транзакції, в якій Аліса переказує гроші Керол у блок L2.
Після отримання транзакції Аліси Sequencer підтверджує результат транзакції та поміщає його в наступний блок
Але Аліса надсилає іншу транзакцію безпосередньо до рівня L1 через примусове включення, що призводить до помилки транзакції Аліси, отриманої секвенсором
Щоб транзакція, вставлена L1, не вплинула на процес упаковки секвенсором блоків L2, Arbitrum не набуде чинності негайно, коли транзакція, вставлена L1, потребує очікування, поки секвенсор активно подає заявку на включення транзакції в останній блок перед він почне діяти, або, якщо секвенсор не відповідає, почне діяти через деякий час. Оптимізм дозволяє транзакції негайно вступити в силу. Якщо транзакція, вставлена L1, впливає на транзакцію в блоці L2, Sequencer повинен знайти спосіб впоратися з нею. Ви можете прочитати цей вступ, щоб дізнатися більше про порівняння між Arbitrum і Optimism під час обробки транзакцій розміщення L1.
Набагато простіший дизайн
Based Rollup має меншу роль Sequencer, ніж загальний Rollup, що означає менше навантаження на апаратне забезпечення (не потрібно турбуватися про завантаження машини Sequencer) і будь-який механізм, щоб зробити транзакції впорядкування більш справедливими (наприклад, механізм децентралізованого Sequencer). Тоді немає потреби в механізмі Force Inclusion/Escape Hatch, включаючи пов’язані з L1 контракти та пов’язані інструменти поза ланцюгом, щоб полегшити користувачам самостійно розміщувати транзакції в L1.
Але Based Rollup також має деякі недоліки:
Немає послуги підтвердження транзакції заздалегідь
За допомогою Sequencer Sequencer може швидко повідомити користувачеві результат виконання його транзакції. Поки користувач довіряє секвенсору, результат транзакції можна підтвердити негайно, не чекаючи, поки транзакція буде завантажена в L1.
У Based Rollup Аліса чекає, поки транзакцію буде завантажено в L1, перш ніж вона повірить, що її транзакцію включено, і їй потрібно дочекатися принаймні одного блоку L1
У загальному зведенні, якщо Аліса вважає, що секвенсор прийме її транзакцію, вона може негайно підтвердити, чи буде транзакція прийнята
Протокол втрачає джерело доходу від MEV
MEV більше не передається секвенсеру для перевірки та вилучення, а L1, тому сам L2 не має можливості отримати переваги MEV. Дохід від MEV можна отримати, розробивши механізм торгів для прав на виробництво блоків, але це відносно збільшить поріг для учасників L1 для участі у виробництві блоків, що зменшить ступінь децентралізації, а запровадження механізму торгів також принесе певного ступеня складності.
Посилання та рекомендована додаткова література