Коротке обговорення Restone: це не плазма, а варіант Optimium

Нещодавно проект під назвою Redstone став гарячою темою. Цей спеціальний інструмент рівня 2 для ланцюжкових ігор, запущений командою Lattice, був офіційно випущений 15 листопада та зараз доступний у тестовій мережі. Цікаво, що команда Lattice заявила: «Redstone — це ланцюжок Alt-DA, натхненний плазмою».

Буквально за день до виходу Redstone Віталік щойно опублікував статтю «Вихід з ігор для валідіумів EVM: повернення Плазми». У статті коротко розглянуто технічне рішення «Плазма», яке зникло з екосистеми Ethereum. І вказано, що для вирішення проблеми Плазми можна запровадити підтвердження дійсності (сплутане з ZK Proof). У зв'язку з цим багато друзів вважають, що Віталік опублікував цю статтю, щоб підтримати Redstone. Деякі люди навіть казали в спільноті гіків Web3, що Віталік міг інвестувати в Redstone. У поєднанні з гарячою «суперечкою щодо визначення рівня 2 Ethereum» у цьому приквелі люди загалом вірили, що це призведе до «відродження плазми» в майбутньому, і в результаті рішення DA поза екосистемою Ethereum, такі як Celestia, можуть бути придушені. Тому що Plasma не має жорстких вимог до DA. Однак, згідно з дослідженнями автора цієї статті, Redstone не відповідає загальним рамкам рішення Plasma. Його заява про те, що він «натхненний Плазмою», насправді може слідувати за гарячими темами статті Віталіка. Справа не в тому, що Віталік справді хоче відстоювати Redstone. Крім того, план виклику DA Redstone дуже схожий на план, запущений проектом рівня 2 Metis у квітні 2022 року, за винятком того, що порядок двох кроків оновлення Stateroot і публікації даних DA відрізняється. Отже, реальна ситуація така, що кожен може «перебільшувати» Редстоун. Нижче пояснюється читачам за допомогою деяких простих міркувань принцип Плазми та чому вона недружня до смарт-контрактів і Defi, і що саме таке Редстоун.

Плазма: у разі атаки на приховування даних потрібні термінові вилучення

Історію Plasma можна простежити до буму ICO Ethereum у 2017 році. У той час попит на транзакції з боку користувачів Ethereum вибухнув, і ETH, який мав низький TPS, був переповнений. На цьому етапі була випущена найраніша теоретична версія Плазми, яка пропонувала план розширення другого рівня, який може впоратися з «майже всіма фінансовими сценаріями у світі». Простіше кажучи, Plasma — це рішення для розширення, яке публікує лише заголовок блоку/корінь Merkle з Layer2 до Layer1. Частина даних (дані DA), окрім заголовка блоку/кореневого коду Merkle, публікується лише поза мережею. Якщо корінь Merkle, виданий сортувальником/оператором Plasma на L1, пов’язаний із недійсною транзакцією (помилка цифрового підпису тощо) , відповідний користувач може подати сертифікат про шахрайство, щоб підтвердити, що корінь, поданий сортувальником, пов’язаний із недійсною транзакцією. Але проблема полягає в тому, що для видачі сертифіката шахрайства необхідно переконатися, що дані DA не приховуються, але Plasma не має суворих вимог до рівня DA і не може гарантувати, що користувачі або вузли L2 можуть отримувати дані. Якщо секвенсор запускається в певний момент часу, атаки із затримкою даних (також відомі як проблеми з доступністю даних) публікують лише нові заголовки блоків/корені Merkle, але не публікують відповідні тіла блоків. Без можливості перевірити, чи заголовок/корінь блоку є дійсний, користувачі можуть використовувати лише «безнадійний» секвенсор за замовчуванням і виводити активи з Рівня 2 на Рівень 1 за допомогою механізму екстреного виходу під назвою «Вихід з гри».

Цей крок вимагає від користувача надати підтвердження Merkle, щоб підтвердити, що він справді має відповідну кількість активів на L2. Ми можемо назвати це «Доказом активів». Що цікаво, так це те, що у Plasma Exit Game та режимі аварійного люка ZK Rollup різні. Користувачі ZK Rollup повинні надати підтвердження Merkle, що відповідає останньому дійсному кореневому кореню держави, тоді як користувачі Plasma можуть надіслати підтвердження, що відповідає кореневому кореню Merkle давно. Чому він так спроектований? Просто тому, що Stateroot, поданий ZK Rollup, буде негайно передано на розгляд контракту на Layer1 (щоб визначити, чи дійсний сертифікат дійсності). Якщо щойно надісланий державний корень є дійсним і законним, тоді користувач повинен надати Merkle Proof, що відповідає законному державному кореню, щоб служити сертифікатом активів. Однак контракт Layer1 не може визначити, чи корінь Merkle, поданий секвенсором Плазми, є дійсним. Він може лише дозволити вузлу L2 активно ініціювати виклик для видалення недійсних коренів, тому буде механізм виклику. Це змушує Plasma та Zk Rollup працювати дуже по-різному. Припустімо, що секвенсор щойно видав недійсний корінь Merkle 101 і запустив атака із затримкою даних, щоб вузол L2 не міг довести, що корінь № 101 недійсний. У цей час користувач може подати доказ merkle, що відповідає кореню № 100 або більш ранньому кореню. Вивести власні активи.

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

У зв’язку з цим Plasma дозволяє будь-кому надати докази шахрайства у вищевказаній ситуації, вказуючи на те, що «доказ активів», поданий користувачем, який ініціював заяву про відкликання, застарів. Завдяки запровадженню «будь-хто може оскаржити чиюсь заявку на зняття коштів», Плазмі не потрібно обробляти екстрені запити на зняття коштів, як-от ZK Rollup. Але все ще існує можливість, тобто секвенсор спочатку переносить активи інших людей на свій власний обліковий запис L2, а потім потім запускає атаку із затримкою даних, щоб сторонні особи не могли оскаржити його шахрайську поведінку. Після цього секвенсер ініціював екстрене зняття коштів зі свого власного облікового запису та надав «доказ активів», стверджуючи, що він справді володіє цими активами на L2. Очевидно, що наразі через відсутність історичного запису люди не можуть прямо довести, що існує проблема з джерелом походження активів сортувальника. Отже, що робити в цій ситуації? Ранні версії Plasma, такі як Plasma MVP, враховували це й запропонували «Пріоритет вилучення». Якщо сертифікат активів, поданий особою, відповідає попередньому кореню, його запит на зняття буде оброблено першим.

Якщо секвенсор виконує вищезазначену шахрайську поведінку та ініціює виведення під час подання кореневого номера 101, тоді користувач може подати сертифікат активу, що відповідає кореневому номеру 99 або раніше, щоб зробити екстрене виведення. Очевидно, що поки сортувальник не зможе підробити історичні записи, які були опубліковані на Рівні 1, користувач матиме спосіб втекти. Але Плазма все ще має фатальну помилку: доки секвенсор ініціює приховування даних, люди повинні покладатися про екстрене зняття коштів (також відоме як Exit Game) для забезпечення безпеки активів. Якщо велика кількість користувачів колективно виведе гроші за короткий проміжок часу, Рівень 1 легко не зможе з цим впоратися; Що серйозніше, хто має вивести активи, записані в контракті Defi, на Рівень 1? Припустімо, хтось стягує 100 ETH на пул LP DEX, а потім секвенсор Плазми виходить з ладу або робить щось погане, і людям потрібно терміново зняти кошти. У цей час 100 ETH користувача все ще контролюються контрактом DEX. На даний момент, якими мають бути ці активи? Хто згадав Layer1? Найкращий спосіб — це спочатку дозволити користувачам викупити свої активи з пулу DEX, а потім дозволити користувачам самим переказати гроші на L1. Однак проблема полягає в тому, що секвенсор плазми несправний/вчинив зло, і користувачі не можуть викупити ресурси. операція. Але якщо ми дозволимо власнику контракту DEX перенести активи, контрольовані контрактом, до L1, це, очевидно, передасть власнику контрактного активу право власності. Він може підняти ці активи до L1 і втекти в будь-який момент. Хіба це не було б жахливо? Тож, зрештою, те, як поводитися з цими «публічними властивостями», контрольованими контрактами Defi, є величезним сюрпризом. Якщо ми дотримуємося соціального консенсусу, видається можливим реконструювати дзеркальний контракт на Рівні 1, який відображає контракт Defi на Рівні 2, але це створить значні проблеми та збільшить альтернативні витрати. Хто буде голосувати, щоб вирішити, як розпоряджатися дзеркальним контрактом? Це буде велика проблема. Це фактично стосується проблеми розподілу публічної влади. Злодії раніше сказали в інтерв’ю: «Важко створювати нові речі у високопродуктивних публічних мережах, смарт-контракти передбачають розподіл потужності».Про це згадувалося в статті.

Звичайно, Віталік також вказав на це у своїй недавній статті «Вихід з ігор для валідіумів EVM: повернення Плазми», і підкреслив, що це один із факторів, який робить Плазму недружньою до смарт-контрактів. Добре відомі варіанти Плазми в минулому , такі як Plasma MVP і Plasma Cash, використовували UTXO або подібні моделі для заміни моделі адреси облікового запису Ethereum і не підтримували смарт-контракти, що дозволяє уникнути проблеми «розподілу власності на активи», згаданої вище. Хоча право власності на кожен UTXO належить самому користувачеві, сам UTXO також має багато недоліків і не є дружнім до смарт-контрактів. Тому рішення Plasma найбільше підходить для простих платежів або обміну книжками замовлень. після цього, із популярністю ZK Rollup, сама Плазма також пішла зі сцени історії. Оскільки Rollup не має проблеми збереження даних, як у Plasma. Якщо секвенсор ZK Rollup запускає атаку із затримкою даних і надсилає в ланцюг ETH лише Stateroot, але не дані DA, такий корінь буде визнано недійсним і безпосередньо відхилено контрактом Verifier на L1. Таким чином, дані DA, що відповідають законному кореневому кореню ZK Rollup, повинні бути доступні в ланцюжку ETH. Ось і все. Немає «лише публікації заголовка блоку чи кореня merkle, але не відповідного тіла блоку», що означає, що це може вирішити проблему доступності даних/атаку приховування даних. У той же час минулі дані Rollup DA можна перевірити на Ethereum, і будь-хто може запустити вузли рівня 2 через історичні записи в ланцюжку ETH, що значно зменшить складність децентралізованих рішень секвенсорів і навіть без дозволів. На відміну від цього, Плазма не має жорстких вимог до DA, і важче реалізувати децентралізований сортувальник (щоб реалізувати змінний децентралізований сортувальник, ми повинні спочатку переконатися, що всі вузли L2 розпізнають той самий блок, що висуває вимоги до реалізації DA .). Крім того, якщо секвенсор ZK Rollup спробує включити недійсні транзакції в блоки рівня 2, це не вдасться. Це гарантується принципом доказу дійсності. Зрештою, зловмисний простір ZK Rollup sorter набагато менший, ніж у Plasma — щонайбільше, він може призупинити оновлення Stateroot, що еквівалентно завершенню роботи на рівні UX, або відхилити певні запити користувачів, загальновідомі як перевірка транзакції. водночас, якщо сортувальник виходить з ладу в схемі зведення, іншим вузлам буде легше замінити його. Ідеальний зведення може зменшити ймовірність запуску режиму виходу з гри в Плазмі до 0 (так званий аварійний люк у ZK Rollup ).

(Стовпець Proposer Failure на L2BEAT показує, як кожне рішення L2 реагує на збій секвенсора. Self Propose часто посилається на інші вузли, які можуть замінити наразі неактивний секвенсор)

Сьогодні майже жодна команда в екосистемі Ethereum не дотримується маршруту Plasma, і майже всі проекти Plasma були мертвонародженими.

(Віталік пояснює, чому ZK Rollup кращий за Plasma, згадуючи роботу секвенсора без дозволу та проблеми з DA)

Що таке Redstone: це не Plasma, а варіант Optimium

Вище ми коротко пояснили Плазму та короткі причини, чому її замінили на Rollup. Щодо Redstone, ви, напевно, також бачили різницю між ним і плазмою: Redstone може вирішити проблему атак із затримкою даних, наприклад, він не випускатиме новий root root одразу. Натомість він спочатку опублікує вихідні дані DA в ланцюжку ETH, а потім використає хеш даних даних DA як пов’язане зобов’язання облікових даних і опублікує його в ланцюжку ETH, повідомивши, що він випустив це в ланцюжку. Повні дані, що відповідають хешу даних сегмента.

(Офіційне пояснення компанії Redstone щодо її плану запобігання атакам із затримкою даних)

Будь-хто може ініціювати виклик, заявивши, що сортувальник Redstone не опублікував оригінальні дані, які відповідають цьому хешу даних поза ланцюгом. у цей час секвенсору потрібно опублікувати дані, що відповідають хешу даних у ланцюжку, щоб відповісти на виклики тих, хто сумнівається. Якщо секвенсору не вдасться опублікувати дані в ланцюжку ETH вчасно після оскарження, хеш даних/зобов’язання, які він опублікував раніше, буде вважати недійсними. Якщо сортувальник вчасно відповідає на запит претендента, претендент може вчасно отримати вихідні дані DA, що відповідають хешу даних. Зрештою, усі вузли L2 можуть в основному отримати необхідні дані DA для вирішення проблеми атак із затримкою даних. звичайно, сам претендент спочатку повинен заплатити комісію, яка приблизно дорівнює вартості секвенсора, який опублікує вихідні дані DA в ланцюжку ETH. Цей захід покликаний запобігти зловмисним претендентам безкоштовно кинути виклик секвенсору, спричиняючи останнім збитки. . нарешті, коли закінчується період виклику для хешу даних, сортувальник вивільнить відповідний корінь стану, тобто корінь, отриманий після виконання послідовності транзакцій, що міститься в даних DA, що відповідають хешу даних. На цьому етапі вузли L2 можуть використовувати систему захисту від шахрайства, щоб оскаржити ці недійсні корені. Якщо сортувальник не звільнить відповідні вихідні дані DA вчасно після оскарження попереднього хешу даних, навіть якщо пізніше сортувальник звільнить корінь стану, що відповідає цьому хешу даних, він буде недійсним за замовчуванням. тому що Redstone спочатку випускає дані DA, а потім випускає відповідний ефективний Stateroot, безпосередньо вирішуючи проблему атак із затримкою даних. сортувальник публікує лише кореневі, а не дані DA). Очевидно, що цей режим відрізняється від звичайного Optimium (OP Rollup, який не використовує Ethereum для реалізації DA, наприклад Arbitrum Nova). Optimium зазвичай покладається на комітет DAC поза ланцюгом, щоб забезпечити доступність даних. DAC надсилає багатопідписаний txn до ланцюга через рівні проміжки часу. Після того, як контракт Rollup на рівні 1 отримає багатопідписаний txn, за замовчуванням секвенсор опублікує останній пакет даних DA поза ланцюгом.

(Джерело: L2beat)

Наприклад, Metis і Arbitrum Nova подають Stateroot і datahash одночасно. Якщо хтось вважає, що сортувальник приховав дані DA, вони спробують оскаржити це, і сортувальник надішле дані DA, що відповідають хешу даних, у ланцюг. Отже, ключова відмінність між Redstone і Metis полягає в цьому кроці: перший випускає хеш даних спочатку, а потім випускає stateroot після закінчення періоду виклику DA; Metis одночасно випускає root і datahash. Якщо хтось ініціює виклик, дані DA завантажуються в ланцюжок. Очевидно, що рішення Redstone безпечніше, тому що згідно з рішенням Metis, якщо сортувальник ніколи не відповідає на запит претендента на дані DA, проблему атаки із затримкою даних неможливо вирішити швидко. Ми можемо покладатися лише на екстрене вилучення та соціальний консенсус або дозволити іншим вузлам взяти на себе поточний сортувальник. ;

Але в Redstone, якщо сортувальник бере участь у приховуванні даних, наданий ним корінь стану вважатиметься недійсним, тому корень стану та дані DA пов’язані. Це дозволяє Redstone отримати гарантію DA, ближчу до гарантії Rollup, яка, по суті, є варіант Optimium, який перевершує Arbitrum Nova і Metis.

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

1. Цю статтю передруковано з [极客web3]. Усі авторські права належать оригінальному автору [Faust]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.