Останнім часом у Twitter багато дискусій точиться навколо децентралізації L2. Чи достатньо децентралізовано зведені пакети, які ми створюємо? Чи принаймні вони на шляху до децентралізації? Це важливо?
Ідея Rollup проста: ми хочемо, щоб учасники поза мережею могли проводити транзакції, які потім можна легко перевірити в мережі. За допомогою Rollup базовий рівень дозволяє використовувати свою базу «довіри» для дій, які відбуваються за межами його безпосередньої сфери. Натомість Rollup сплачує невелику плату (орендну плату), щоб використати цю довіру.
Отже, чи потрібні нам децентралізовані зведені пакети?
Інтуїтивна відповідь - так! Це дух, у якому ми будуємо блокчейн.
Однак я вважаю, що відповідь на це запитання не є простою так чи ні. Натомість він має кілька аспектів, які потрібно аналізувати окремо. У наступних розділах я розберу це питання з трьох точок зору: філософської, технологічної та економічної. ****Ці три не обов’язково є вичерпними або виключними, але вони повинні давати гарне загальне бачення проблеми. **
1. Філософська перспектива
Давайте почнемо з того, що підіймемо розмову на новий рівень – чому нам потрібна децентралізація?
Тому що ми хочемо бездозволеного майбутнього, яке сприяє відкритим інноваціям. Ми хочемо, щоб користувачі могли створювати нові речі без будь-яких обмежень і без необхідності довіряти будь-якому окремому суб’єкту.
За коротку історію блокчейну у нас було багато анонімних розробників, які створювали дивовижні речі. Фактично, сам біткойн був створений анонімною організацією - незабаром він може стати валютою, яку більшість людей у світі використовують для глобальних платежів! Це сила інновацій без дозволу!
Блокчейн дозволяє нам співпрацювати з людьми, які не мають нічого спільного, і ми знаємо, що вони не можуть порушити цю довіру - Престон Еванс
Децентралізована основа безнадійних мереж, таких як Bitcoin та Ethereum, дозволяє нам будувати таке майбутнє. Тоді очевидно, що будь-який ланцюг, який має довірчі відносини з цими ланцюгами, наприклад Rollups, також має бути децентралізованим!
Фактично, це піднімає цікаве та важливе питання:
**Якщо Rollup не децентралізований, чи означає це, що Ethereum не децентралізований? **
Трохи оптимістичний погляд на це полягає в тому, що у світі без дозволів зведенням слід дозволити створювати все, що завгодно, включаючи (але не обмежуючись ними) повністю дозволені ланцюжки, і користувачі цього зведення все одно повинні мати можливість використовувати безпеку на базовий шар. Навіть дозволені ланцюжки мають бути безпечними для використання, якщо базовий рівень децентралізований і зведення «повністю» реалізовано (ми поговоримо більше про «повністю реалізовано» в технічному розділі).
Але насправді більшість зведених пакетів ще не досягли стадії повного впровадження, і вони не забезпечують користувачам бажаний рівень безпеки та надійності.
Отже, як виглядає правильна реалізація зведення? давайте подивимось:
2. Технологія
Щоб по-справжньому зрозуміти питання децентралізації та безпеки на рівні зведення, нам потрібно поглянути на це з перших принципів. Мало хто може пояснити перші принципи блокчейна краще, ніж Срірам Каннан.
Блокчейн — це розподілена книга, де різні вузли в мережі дотримуються визначеного протоколу, щоб отримати консенсус щодо стану книги. Залежно від того, як ці вузли бачать мережу, вони можуть мати різні правила для підтвердження правильного стану мережі у власній книзі.
Наприклад, у протоколі Gasper Ethereum є два різних правила підтвердження – доступне правило (на основі найважчого ланцюга) і остаточне правило (на основі блоків, підтверджених гаджетом).
Особливо в зведених вузлах повні вузли мають інші правила підтвердження, ніж легкі клієнти. У традиційному зведеному розумному контракті (SCR) смарт-контракт (міст перевірки) має власні правила підтвердження. Якщо побічних явищ немає, ці правила підтвердження зрештою збігаються в так званих «областях узгодженості». Як випливає з назви, у зонах консенсусу всі учасники мають однакове уявлення про мережу (і мають однакову історію у своїх книгах).
Якщо всі правила підтвердження безпечні, нічого поганого не станеться. Як поділився Шрірам у наведеній вище публікації, 5 властивостей в основному визначають безпеку цих правил підтвердження.
Зростання бухгалтерської книги - ланцюжок зведених даних має продовжувати зростати (жвавість)
Стійкість до цензури - усі користувачі повинні мати можливість включати будь-які транзакції в базовий рівень
Стійкість до реструктуризації - трансакція не повинна бути відновлена після завершення
Доступність даних - дані про трансакції мають бути десь опубліковані
Дійсність - транзакції та зміни стану мають бути дійсними
Перші 2 властивості разом визначають «живий» стан системи, тоді як останні 3 властивості визначають «безпечний» стан.
Давайте подивимося на кожного з точки зору різних учасників агрегації та побачимо, які з них можна пом’якшити без децентралізації.
Різні актори покладаються на різні механізми безпеки та живучості
Повний вузол:
Якщо ви запускаєте повний вузол, ви маєте доступ до опублікованих даних і можете перевірити їх безпосередньо. Потім ви можете використовувати ці дані, щоб самостійно виконувати транзакції та визначати дійсність транзакцій і остаточний стан зведення після цих транзакцій.
Таким чином, іншими умовами безпеки є властивості активності та стійкість до рекомбінації. Для останнього повні вузли покладаються на валідатори основного ланцюга та протокол консенсусу, який вони використовують, тоді як для властивостей живучості повні вузли покладаються на реалізацію секвенсора та Rollup.
Легкий клієнт:
Більшість користувачів використовують гаманці, вбудовані в легкі вузли, або використовують сторонні служби для отримання даних блокчейну та взаємодії з блокчейном. Світлові вузли можуть бути різних типів:
State Validator - перевірка дійсності переходів станів,
DA Validator - Перевіряє доступність даних,
**консенсус-валідатор - перевірка консенсус-доказу базового рівня або **
повний верифікатор - перевіряє все вищезазначене
Якщо ви запускаєте легкий клієнт повної перевірки, ви можете перевірити, що дані доступні за допомогою вибірки доступності даних, ви можете перевірити дійсність переходів станів за допомогою доказів дійсності або доказів шахрайства, ви також можете перевірити, що стан було остаточно визначено на основі Консенсус шару (на Ethereum це можна зробити, дотримуючись комітету синхронізації).
Тоді умова безпеки, що залишилася, є властивістю живучості, і легкі клієнти покладаються на реалізацію секвенсора та зведення.
Вбудований смарт-контракт (перехідний міст):
У традиційному SCR «правило підтвердження» смарт-контракту полягає в застосуванні всіх 5 властивостей безпеки:
Зростання книги через протокол заміни секвенсора
Протистояти цензурі, забезпечуючи включення
Створіть стійкість до реорганізації лише на основі попереднього стану
Доступність даних досягається шляхом подання DA на базовому рівні
Перевірка дійсності за допомогою підтвердження дійсності/шахрайства
Повні вузли SCR покладаються на смарт-контракти для забезпечення властивостей живучості. Вони «поглинають» опір реструктуризації з базового шару.
Легкі вузли покладаються на розумні контракти для покращення властивостей живучості та поглинання опору DA та реорганізації базового рівня. Вони можуть перевірити підтвердження дійсності самостійно або за допомогою смарт-контрактів.
Консенсус SCR полягає в тому, щоб слідувати канонічному ланцюжку, визначеному смарт-контрактом.
**А як щодо Sovereign Rollup? **
У Sovereign Rollups немає смарт-контрактів (мостів перевірки), які б забезпечували дотримання умов дійсності чи живучості. Замість цього вони будуть «згортатися» до нижнього вузла згортання. Ці вузли все ще поглинають опір DA та Reorg базового шару.
Так само, як і в SCR, у суверенних вузлах зведення потрібен певний механізм для забезпечення властивості живучості. Щоб визначити канонічний ланцюг, вони вибрали незалежні механізми, такі як трансляція доказів p2p.
Яке все це має відношення до децентралізації?
Незалежно від того, чи це зведення смарт-контрактів, чи зведення суверенних зобов’язань, властивість живучості походить від правильного впровадження зведення. Як ми бачили вище, правильна реалізація агрегації повинна містити два важливі компоненти:
обов'язкові механізми включення, і
Протокол заміни секвенсора
Обов’язкове включення допомагає створити опір цензурі. Цей механізм дозволяє користувачам «примусово включати» свої транзакції безпосередньо в базовий рівень. Потім будь-який користувач у зведенні може примусово повернутися до базового рівня за допомогою своїх коштів. Таким чином, навіть якщо існує лише один централізований вузол сортування для агрегації, він не може цензурувати користувачів, доки існує зрілий механізм примусового виконання.
Але чи достатньо цього?
Навіть якщо користувачі можуть вийти з системи, це може означати, що якщо більшість користувачів повертаються до L1, підприємство не матиме особливого стимулу продовжувати працювати. Крім того, механізм обов’язкового включення зазвичай має тривалий час очікування, і його впровадження може бути досить дорогим для середнього користувача. Опір цензурі, який забезпечує цей механізм, не зовсім практичний (або в реальному часі). Цю ситуацію можна назвати «слабкою цензурою».
Потім у нас є останній атрибут живучості – зростання книги
Якщо централізований сортувальник стає зловмисним, він може зупинити зростання підсумкового ланцюжка, просто зупинивши виробництво блоків. Якщо це трапиться, користувач або компанія нічого не зможуть зробити, щоб знову «запустити» зведення.
Щоб вирішити цю проблему, нам потрібен протокол заміни секвенсора.
Ідея протоколу заміни секвенсора полягає в тому, що якщо секвенсор поводиться зловмисним чином, агрегатне керування може запустити секвенсор. Одним із способів досягти цього є заміна централізованих вузлів секвенсора на децентралізований протокол секвенсора. Якщо сортувальник децентралізований і не монополізує будівельні блоки зведення, зупинити зведення практично неможливо.
Таким чином, хоча кошти користувачів завжди в безпеці в Rollups завдяки обов’язковому механізму включення, створення надійного протоколу заміни замовника допомагає підтримувати Rollups і забезпечує практичний захист від цензури в реальному часі.
це все?
Не зовсім. З технічної точки зору варто врахувати ще один аспект:
Що, якби самі смарт-контракти могли бути оновлені об’єднаним центральним комітетом? Скажімо, зведення наразі реалізовано правильно, але завтра комітет погодиться, що нам більше не потрібні смарт-контракти, а натомість транслюватимуть докази стану зведення в мережу p2p.
Якщо, як користувач зведеного оновлення, ви не згодні з таким оновленням, ви повинні мати можливість вийти з зведеного оновлення до впровадження оновлення (хоча, знову ж таки, це не дуже добре для користувача та може бути поганим для бізнесу). Цього можна досягти за допомогою «відстрочених оновлень управління». Це ніби «період сповіщення», після якого буде реалізовано оновлення. Користувачі, які не погоджуються на оновлення, можуть відмовитися протягом періоду повідомлення.
Крайністю децентралізації є можливість мати повністю незмінні розумні контракти. Ці контракти не регулюються жодним гаманцем із мультипідписом чи іншим комітетом, і після розгортання вони ніколи не можуть бути оновлені.
Звичайно, тут є свої проблеми. Якщо в коді є якісь помилки або якась серйозна подія потребує оновлення смарт-контракту, єдиним вибором для вузла агрегації є перехід до нового смарт-контракту, залишаючи кошти користувача в старому контракті.
поточний стан
На жаль, поточний стан Rollup далеко не повноцінний, про який ми говорили вище. Більшість зведень все ще перебувають у фазі «навчальних коліс», намагаючись зробити це правильно.
Відповідно до L2BEAT, Fuel v1 і DeGate є єдиними двома агрегатами, які досягли всіх умов діяльності та безпеки.
3. Економіка
Давайте подивимося на економіку Rollup з точки зору користувачів і операторів Rollup:
1) Взаємодія з користувачем - користувачі повинні отримувати низькі ціни та не чекати занадто довго на транзакції
2) Зведений прибуток - для сортувальників і власників токенів має бути вигідно використовувати Rollup
Взаємодія з користувачем оптимізована, коли користувачі отримують швидкі та дешеві транзакції.
Швидкість завершення транзакцій залежить від швидкості завершення блоків базового рівня. Транзакції можна вважати остаточними щоразу, коли дані на L1 завершені. Однак користувачі, які використовують повні вузли, також можуть досягти миттєвої завершеності, просто виконавши транзакції та визначивши кінцевий стан.
Але не всім практично використовувати повний вузол. Таким чином, централізований сортувальник корисний, оскільки він може надавати користувачам «м’яке підтвердження», що їх транзакція включена в блок і буде завершена. Цього достатньо для більшості випадків використання. Однак це передбачає опору на центральну партію, яка може діяти проти неї.
У той час як деякі рішення альтернативного протоколу секвенсора (наприклад, засновані на зведених пакетах) уникають цієї властивості на шкоду користувачам, інші рішення (наприклад, зовнішній консенсус POS (наприклад, Espresso)) можуть надавати подібні гарантії попереднього підтвердження, не зазнаючи такого ризику: централізований секвенсор.
Як щодо вартості для користувача?
Явна ціна зведеної транзакції зазвичай становить:
Вартість газу L2 = Вартість газу L1 + Комісія за секвенсор
Центральний замовник, діючи раціонально, завжди прагне максимізувати власні прибутки, навіть якщо це означає перекладання вищих витрат на користувачів. Однак варто зазначити, що це також не обов’язково можна вирішити за допомогою децентралізованого механізму сортування. Навіть POS-вузли в децентралізованому замовнику хочуть максимізувати власні прибутки.
Насправді це створює проблему неузгодженості, коли агрегат може не захотіти передавати прибуток зовнішньому сортувальнику.
Rollup Profit. Окрім комісії секвенсора, Rollup також може отримувати прибуток, витягуючи MEV із масових транзакцій користувачів. Цей MEV часто важко віднести, оскільки важко з’ясувати, чи включив замовник деякі з власних первинних транзакцій у пакет.
**Якщо Rollup буде замінено зовнішнім консенсусом POS, вони передадуть цей MEV зовнішнім операторам. **
Варто зазначити, що обидві ці проблеми, пов’язані з передачею прибутків Rollups зовнішнім механізмам, можна вирішити за допомогою «торгових угод» між Rollups і зовнішніми механізмами, у яких можна вирішити комісійні збори та MEV, створені внутрішніми та крос-зведеними транзакціями. Перенаправляє назад до резюме.
Однак, як пояснювалося у виступі Джона Шарбоно під час Модульного саміту та наступних дописів, кращою ідеєю може бути делегування зведеного керування для набору дозволених вузлів. Ці вузли можна стратегічно вибрати так, щоб вони були географічно розосереджені, і управління може просто вигнати поганих гравців.
**Це може бути комплексним рішенням, оскільки воно дозволяє згортанням зберігати маржу всередині підприємства, а також пом’якшує негативний вплив централізованих сортувальників. **
Але протилежним цьому є те, що за обмеженої ротації сортувальників сортувальники можуть мати некороткозору поведінку, що може призвести до монопольного ціноутворення/підвищення цін за рахунок користувачів агрегації.
У будь-якому випадку, зрозуміло, що певний протокол заміни секвенсора необхідний для того, щоб узагальнення було економічно ефективним для користувачів. Чи є це доказом правління, механізмом зовнішнього консенсусу чи чимось іншим – це тема для окремої статті.
4 Висновок
Сподіваюся, тепер стало зрозуміло, яким би шляхом не йшов Rollup, важливо, щоб метою було повне впровадження зі зрілими механізмами для заміни сортувальника, примусового включення та оновлень управління затримками. Навіть якщо це лише обов’язкове включення та затримки оновлень, кошти користувачів у безпеці, коли Rollup повністю впроваджено, незалежно від того, чи є координатор централізованим.
Однак надійний протокол заміни секвенсора може покращити гарантії життєдіяльності та потенційно покращити економіку користувачів Rollup.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Подивіться на важливість зведеної децентралізації з трьох аспектів
Автор: Шиваншу Мадан; Упорядник: Huohuo/Veracular Blockchain
Останнім часом у Twitter багато дискусій точиться навколо децентралізації L2. Чи достатньо децентралізовано зведені пакети, які ми створюємо? Чи принаймні вони на шляху до децентралізації? Це важливо?
Ідея Rollup проста: ми хочемо, щоб учасники поза мережею могли проводити транзакції, які потім можна легко перевірити в мережі. За допомогою Rollup базовий рівень дозволяє використовувати свою базу «довіри» для дій, які відбуваються за межами його безпосередньої сфери. Натомість Rollup сплачує невелику плату (орендну плату), щоб використати цю довіру.
Отже, чи потрібні нам децентралізовані зведені пакети?
Інтуїтивна відповідь - так! Це дух, у якому ми будуємо блокчейн.
Однак я вважаю, що відповідь на це запитання не є простою так чи ні. Натомість він має кілька аспектів, які потрібно аналізувати окремо. У наступних розділах я розберу це питання з трьох точок зору: філософської, технологічної та економічної. ****Ці три не обов’язково є вичерпними або виключними, але вони повинні давати гарне загальне бачення проблеми. **
1. Філософська перспектива
Давайте почнемо з того, що підіймемо розмову на новий рівень – чому нам потрібна децентралізація?
Тому що ми хочемо бездозволеного майбутнього, яке сприяє відкритим інноваціям. Ми хочемо, щоб користувачі могли створювати нові речі без будь-яких обмежень і без необхідності довіряти будь-якому окремому суб’єкту.
За коротку історію блокчейну у нас було багато анонімних розробників, які створювали дивовижні речі. Фактично, сам біткойн був створений анонімною організацією - незабаром він може стати валютою, яку більшість людей у світі використовують для глобальних платежів! Це сила інновацій без дозволу!
Децентралізована основа безнадійних мереж, таких як Bitcoin та Ethereum, дозволяє нам будувати таке майбутнє. Тоді очевидно, що будь-який ланцюг, який має довірчі відносини з цими ланцюгами, наприклад Rollups, також має бути децентралізованим!
Фактично, це піднімає цікаве та важливе питання:
**Якщо Rollup не децентралізований, чи означає це, що Ethereum не децентралізований? **
Трохи оптимістичний погляд на це полягає в тому, що у світі без дозволів зведенням слід дозволити створювати все, що завгодно, включаючи (але не обмежуючись ними) повністю дозволені ланцюжки, і користувачі цього зведення все одно повинні мати можливість використовувати безпеку на базовий шар. Навіть дозволені ланцюжки мають бути безпечними для використання, якщо базовий рівень децентралізований і зведення «повністю» реалізовано (ми поговоримо більше про «повністю реалізовано» в технічному розділі).
Але насправді більшість зведених пакетів ще не досягли стадії повного впровадження, і вони не забезпечують користувачам бажаний рівень безпеки та надійності.
Отже, як виглядає правильна реалізація зведення? давайте подивимось:
2. Технологія
Щоб по-справжньому зрозуміти питання децентралізації та безпеки на рівні зведення, нам потрібно поглянути на це з перших принципів. Мало хто може пояснити перші принципи блокчейна краще, ніж Срірам Каннан.
Блокчейн — це розподілена книга, де різні вузли в мережі дотримуються визначеного протоколу, щоб отримати консенсус щодо стану книги. Залежно від того, як ці вузли бачать мережу, вони можуть мати різні правила для підтвердження правильного стану мережі у власній книзі.
Наприклад, у протоколі Gasper Ethereum є два різних правила підтвердження – доступне правило (на основі найважчого ланцюга) і остаточне правило (на основі блоків, підтверджених гаджетом).
Особливо в зведених вузлах повні вузли мають інші правила підтвердження, ніж легкі клієнти. У традиційному зведеному розумному контракті (SCR) смарт-контракт (міст перевірки) має власні правила підтвердження. Якщо побічних явищ немає, ці правила підтвердження зрештою збігаються в так званих «областях узгодженості». Як випливає з назви, у зонах консенсусу всі учасники мають однакове уявлення про мережу (і мають однакову історію у своїх книгах).
Якщо всі правила підтвердження безпечні, нічого поганого не станеться. Як поділився Шрірам у наведеній вище публікації, 5 властивостей в основному визначають безпеку цих правил підтвердження.
Перші 2 властивості разом визначають «живий» стан системи, тоді як останні 3 властивості визначають «безпечний» стан.
Давайте подивимося на кожного з точки зору різних учасників агрегації та побачимо, які з них можна пом’якшити без децентралізації.
Різні актори покладаються на різні механізми безпеки та живучості
Повний вузол:
Якщо ви запускаєте повний вузол, ви маєте доступ до опублікованих даних і можете перевірити їх безпосередньо. Потім ви можете використовувати ці дані, щоб самостійно виконувати транзакції та визначати дійсність транзакцій і остаточний стан зведення після цих транзакцій.
Таким чином, іншими умовами безпеки є властивості активності та стійкість до рекомбінації. Для останнього повні вузли покладаються на валідатори основного ланцюга та протокол консенсусу, який вони використовують, тоді як для властивостей живучості повні вузли покладаються на реалізацію секвенсора та Rollup.
Легкий клієнт:
Більшість користувачів використовують гаманці, вбудовані в легкі вузли, або використовують сторонні служби для отримання даних блокчейну та взаємодії з блокчейном. Світлові вузли можуть бути різних типів:
Якщо ви запускаєте легкий клієнт повної перевірки, ви можете перевірити, що дані доступні за допомогою вибірки доступності даних, ви можете перевірити дійсність переходів станів за допомогою доказів дійсності або доказів шахрайства, ви також можете перевірити, що стан було остаточно визначено на основі Консенсус шару (на Ethereum це можна зробити, дотримуючись комітету синхронізації).
Тоді умова безпеки, що залишилася, є властивістю живучості, і легкі клієнти покладаються на реалізацію секвенсора та зведення.
Вбудований смарт-контракт (перехідний міст):
У традиційному SCR «правило підтвердження» смарт-контракту полягає в застосуванні всіх 5 властивостей безпеки:
Повні вузли SCR покладаються на смарт-контракти для забезпечення властивостей живучості. Вони «поглинають» опір реструктуризації з базового шару.
Легкі вузли покладаються на розумні контракти для покращення властивостей живучості та поглинання опору DA та реорганізації базового рівня. Вони можуть перевірити підтвердження дійсності самостійно або за допомогою смарт-контрактів.
Консенсус SCR полягає в тому, щоб слідувати канонічному ланцюжку, визначеному смарт-контрактом.
**А як щодо Sovereign Rollup? **
У Sovereign Rollups немає смарт-контрактів (мостів перевірки), які б забезпечували дотримання умов дійсності чи живучості. Замість цього вони будуть «згортатися» до нижнього вузла згортання. Ці вузли все ще поглинають опір DA та Reorg базового шару.
Так само, як і в SCR, у суверенних вузлах зведення потрібен певний механізм для забезпечення властивості живучості. Щоб визначити канонічний ланцюг, вони вибрали незалежні механізми, такі як трансляція доказів p2p.
Яке все це має відношення до децентралізації?
Незалежно від того, чи це зведення смарт-контрактів, чи зведення суверенних зобов’язань, властивість живучості походить від правильного впровадження зведення. Як ми бачили вище, правильна реалізація агрегації повинна містити два важливі компоненти:
обов'язкові механізми включення, і
Протокол заміни секвенсора
Обов’язкове включення допомагає створити опір цензурі. Цей механізм дозволяє користувачам «примусово включати» свої транзакції безпосередньо в базовий рівень. Потім будь-який користувач у зведенні може примусово повернутися до базового рівня за допомогою своїх коштів. Таким чином, навіть якщо існує лише один централізований вузол сортування для агрегації, він не може цензурувати користувачів, доки існує зрілий механізм примусового виконання.
Але чи достатньо цього?
Навіть якщо користувачі можуть вийти з системи, це може означати, що якщо більшість користувачів повертаються до L1, підприємство не матиме особливого стимулу продовжувати працювати. Крім того, механізм обов’язкового включення зазвичай має тривалий час очікування, і його впровадження може бути досить дорогим для середнього користувача. Опір цензурі, який забезпечує цей механізм, не зовсім практичний (або в реальному часі). Цю ситуацію можна назвати «слабкою цензурою».
Потім у нас є останній атрибут живучості – зростання книги
Якщо централізований сортувальник стає зловмисним, він може зупинити зростання підсумкового ланцюжка, просто зупинивши виробництво блоків. Якщо це трапиться, користувач або компанія нічого не зможуть зробити, щоб знову «запустити» зведення.
Щоб вирішити цю проблему, нам потрібен протокол заміни секвенсора.
Ідея протоколу заміни секвенсора полягає в тому, що якщо секвенсор поводиться зловмисним чином, агрегатне керування може запустити секвенсор. Одним із способів досягти цього є заміна централізованих вузлів секвенсора на децентралізований протокол секвенсора. Якщо сортувальник децентралізований і не монополізує будівельні блоки зведення, зупинити зведення практично неможливо.
Таким чином, хоча кошти користувачів завжди в безпеці в Rollups завдяки обов’язковому механізму включення, створення надійного протоколу заміни замовника допомагає підтримувати Rollups і забезпечує практичний захист від цензури в реальному часі.
це все?
Не зовсім. З технічної точки зору варто врахувати ще один аспект:
Що, якби самі смарт-контракти могли бути оновлені об’єднаним центральним комітетом? Скажімо, зведення наразі реалізовано правильно, але завтра комітет погодиться, що нам більше не потрібні смарт-контракти, а натомість транслюватимуть докази стану зведення в мережу p2p.
Якщо, як користувач зведеного оновлення, ви не згодні з таким оновленням, ви повинні мати можливість вийти з зведеного оновлення до впровадження оновлення (хоча, знову ж таки, це не дуже добре для користувача та може бути поганим для бізнесу). Цього можна досягти за допомогою «відстрочених оновлень управління». Це ніби «період сповіщення», після якого буде реалізовано оновлення. Користувачі, які не погоджуються на оновлення, можуть відмовитися протягом періоду повідомлення.
Крайністю децентралізації є можливість мати повністю незмінні розумні контракти. Ці контракти не регулюються жодним гаманцем із мультипідписом чи іншим комітетом, і після розгортання вони ніколи не можуть бути оновлені.
Звичайно, тут є свої проблеми. Якщо в коді є якісь помилки або якась серйозна подія потребує оновлення смарт-контракту, єдиним вибором для вузла агрегації є перехід до нового смарт-контракту, залишаючи кошти користувача в старому контракті.
поточний стан
На жаль, поточний стан Rollup далеко не повноцінний, про який ми говорили вище. Більшість зведень все ще перебувають у фазі «навчальних коліс», намагаючись зробити це правильно.
Відповідно до L2BEAT, Fuel v1 і DeGate є єдиними двома агрегатами, які досягли всіх умов діяльності та безпеки.
3. Економіка
Давайте подивимося на економіку Rollup з точки зору користувачів і операторів Rollup:
1) Взаємодія з користувачем - користувачі повинні отримувати низькі ціни та не чекати занадто довго на транзакції
2) Зведений прибуток - для сортувальників і власників токенів має бути вигідно використовувати Rollup
Взаємодія з користувачем оптимізована, коли користувачі отримують швидкі та дешеві транзакції.
Швидкість завершення транзакцій залежить від швидкості завершення блоків базового рівня. Транзакції можна вважати остаточними щоразу, коли дані на L1 завершені. Однак користувачі, які використовують повні вузли, також можуть досягти миттєвої завершеності, просто виконавши транзакції та визначивши кінцевий стан.
Але не всім практично використовувати повний вузол. Таким чином, централізований сортувальник корисний, оскільки він може надавати користувачам «м’яке підтвердження», що їх транзакція включена в блок і буде завершена. Цього достатньо для більшості випадків використання. Однак це передбачає опору на центральну партію, яка може діяти проти неї.
У той час як деякі рішення альтернативного протоколу секвенсора (наприклад, засновані на зведених пакетах) уникають цієї властивості на шкоду користувачам, інші рішення (наприклад, зовнішній консенсус POS (наприклад, Espresso)) можуть надавати подібні гарантії попереднього підтвердження, не зазнаючи такого ризику: централізований секвенсор.
Як щодо вартості для користувача?
Явна ціна зведеної транзакції зазвичай становить:
Вартість газу L2 = Вартість газу L1 + Комісія за секвенсор
Центральний замовник, діючи раціонально, завжди прагне максимізувати власні прибутки, навіть якщо це означає перекладання вищих витрат на користувачів. Однак варто зазначити, що це також не обов’язково можна вирішити за допомогою децентралізованого механізму сортування. Навіть POS-вузли в децентралізованому замовнику хочуть максимізувати власні прибутки.
Насправді це створює проблему неузгодженості, коли агрегат може не захотіти передавати прибуток зовнішньому сортувальнику.
Rollup Profit. Окрім комісії секвенсора, Rollup також може отримувати прибуток, витягуючи MEV із масових транзакцій користувачів. Цей MEV часто важко віднести, оскільки важко з’ясувати, чи включив замовник деякі з власних первинних транзакцій у пакет.
**Якщо Rollup буде замінено зовнішнім консенсусом POS, вони передадуть цей MEV зовнішнім операторам. **
Варто зазначити, що обидві ці проблеми, пов’язані з передачею прибутків Rollups зовнішнім механізмам, можна вирішити за допомогою «торгових угод» між Rollups і зовнішніми механізмами, у яких можна вирішити комісійні збори та MEV, створені внутрішніми та крос-зведеними транзакціями. Перенаправляє назад до резюме.
Однак, як пояснювалося у виступі Джона Шарбоно під час Модульного саміту та наступних дописів, кращою ідеєю може бути делегування зведеного керування для набору дозволених вузлів. Ці вузли можна стратегічно вибрати так, щоб вони були географічно розосереджені, і управління може просто вигнати поганих гравців.
**Це може бути комплексним рішенням, оскільки воно дозволяє згортанням зберігати маржу всередині підприємства, а також пом’якшує негативний вплив централізованих сортувальників. **
Але протилежним цьому є те, що за обмеженої ротації сортувальників сортувальники можуть мати некороткозору поведінку, що може призвести до монопольного ціноутворення/підвищення цін за рахунок користувачів агрегації.
У будь-якому випадку, зрозуміло, що певний протокол заміни секвенсора необхідний для того, щоб узагальнення було економічно ефективним для користувачів. Чи є це доказом правління, механізмом зовнішнього консенсусу чи чимось іншим – це тема для окремої статті.
4 Висновок
Сподіваюся, тепер стало зрозуміло, яким би шляхом не йшов Rollup, важливо, щоб метою було повне впровадження зі зрілими механізмами для заміни сортувальника, примусового включення та оновлень управління затримками. Навіть якщо це лише обов’язкове включення та затримки оновлень, кошти користувачів у безпеці, коли Rollup повністю впроваджено, незалежно від того, чи є координатор централізованим.
Однак надійний протокол заміни секвенсора може покращити гарантії життєдіяльності та потенційно покращити економіку користувачів Rollup.