Останнім часом гарячою темою став проект під назвою Redstone. **Цей об'єкт Layer2, запущений командою Lattice, був офіційно випущений 15 листопада і зараз запущений у тестовій мережі. Цікаво, що команда Lattice стверджує, що «Redstone — це ланцюг Alt-DA, натхненний плазмою».
Буквально за день до релізу Redstone Віталік опублікував статтю «Exit games for EVM validiums: the return of Plasma», в якій він коротко розглянув технічне рішення «Plasma», яке зникло з екосистеми Ethereum, і зазначив, що для вирішення проблеми Плазми можуть бути введені докази валідності (які плутають з ZK Proof).
У зв'язку з цим багато друзів вважають, що Віталік опублікував цю статтю для того, щоб дати Редстоуну платформу, і навіть у гік-спільноті Web3 деякі люди кажуть, що Віталік не інвестував у Redstone. У поєднанні з киплячою «суперечкою про визначення рівня 2 Ethereum» у попередніх чутках, широко поширена думка, що буде запущено наступне «відродження Плазми», і рішення DA за межами екосистеми Ethereum, такі як Celestia, можуть бути придушені, оскільки Plasma не має жорстких вимог до DA. **
Однак, згідно з дослідженням автора цієї статті, Редстоун не вписується в загальні рамки розчину Плазми, і його заява про те, що він «натхненний Плазмою», має можливість втерти жар статті Віталіка, а не те, що Віталік дійсно хоче відстоювати Редстоун. Крім того, виклик DA від Redstone схожий на проєкт рівня 2 Metis, запущений у квітні 2022 року, за винятком того, що порядок оновлення Stateroot та публікації даних DA відрізняється.
Отже, реальна ситуація полягає в тому, що ви, можливо, «надмірно інтерпретували» Редстоун. Нижче наведено просте пояснення того, як працює Плазма, чому вона не є дружньою до смарт-контрактів та DeFi, і що таке Redstone. **
Плазма: Термінове вилучення даних у разі атаки на приховування даних
Історію плазми можна простежити до буму Ethereum IC0 у 2017 році, коли попит на транзакції користувачів Ethereum різко зріс, а ETH з низьким TPS був перевантажений. На цьому етапі було випущено найранішу теоретичну версію Плазми, яка пропонувала схему масштабування рівня 2, яка могла б працювати з «майже всіма фінансовими сценаріями у світі».
Простіше кажучи, Плазма — це рішення для масштабування, яке публікує лише заголовок блоку рівня 2/корінь Меркла до рівня 1, а частина даних поза заголовком блоку/коренем Меркла (дані DA) публікується лише поза мережею. **Якщо кореневий каталог Меркла, опублікований секвенсером/оператором Плазми на L1, пов'язаний з некоректною транзакцією (наприклад, помилка цифрового підпису), користувач може надіслати сертифікат шахрайства, щоб довести, що кореневий каталог, надісланий секвенсером, пов'язаний із недійсною транзакцією.
Проблема полягає в тому, що для того, щоб видавати докази шахрайства, необхідно переконатися, що дані DA не приховуються, але Плазма не має жорстких вимог до рівня DA і не може гарантувати, що користувачі або вузли L2 зможуть отримувати дані. Якщо секвенсер запускає атаку приховування даних (також відому як проблема доступності даних) у певний момент часу і публікує лише новий заголовок блоку/корінь Меркла, але не публікує відповідне тіло блоку, що унеможливлює перевірку, чи дійсний заголовок/корінь блоку, користувач може лише за замовчуванням визнати секвенсор «безнадійним» і вивести активи з рівня 2 на рівень 1 через механізм аварійного виходу під назвою «Гра на виході».
Цей крок вимагає, щоб користувач надав доказ Меркла, щоб довести, що він має відповідну суму активів на L2, яку ми можемо назвати «Proof of Assets». Цікаво, що вихідна гра у Плазмі відрізняється від режиму Escape Pod у ZK Rollup, де користувачі ZK Rollup мають надсилати доказ Меркла, що відповідає найновішому коректному Stateroot, тоді як користувачі Плазми можуть надсилати докази, що відповідають кореневому коду Меркла, створеному давно.
Чому він так влаштований? Просто Stateroot, представлений ZK Rollup, буде негайно поставлений в суд контрактом на рівні 1 (щоб визначити, чи дійсний доказ дійсності). Якщо щойно поданий Stateroot є дійсним і легітимним, то користувач повинен надати доказ Меркла, що відповідає дійсному Stateroot, як доказ активів.
Втім, Корінь Меркла, надісланий секвенсором Плазми, контракт Layer1 не може судити про те, дійсний він чи ні, і може лише дозволити вузлу L2 взяти на себе ініціативу щодо виклику, щоб виключити недійсний Root, тому існуватиме механізм виклику, який робить роботу Плазми та Zk Rollup дуже різною. **
Припустимо, секвенсор тільки що випустив недійсний Merkle Root 101 і запустив атаку приховування даних, так що вузол L2 не може довести, що корінь 101 недійсний, тоді користувач може відправити доказ Меркла, що відповідає root 100 або більш ранньому root, і вивести свої активи.
Звичайно, тут є проблема, яку потрібно вирішити, тобто користувач може подати сертифікат активу, що відповідає root 30 або більш ранній, і запросити виведення активу на рівень 1, але статус активу цієї особи може змінитися після виходу root 30. Іншими словами, він подає застарілий доказ активів, що є типовою атакою подвійних витрат/подвійних витрат. **
У відповідь на це Plasma дозволяє будь-кому надати сертифікат про шахрайство для вищевказаних випадків, стверджуючи, що «доказ справедливості», наданий користувачем, який ініціював заяву про відкликання, є застарілим. Запровадивши принцип «будь-хто може оскаржити чужу інструкцію щодо виведення коштів», Плазмі не потрібно обробляти екстрені запити на виведення коштів, як ZK Rollup.
Але все ще існує ймовірність того, що сортувальник переведе чужі активи на власний обліковий запис L2, перш ніж запустити атаку на приховування даних, яка унеможливлює для сторонніх оскаржити їхнє шахрайство. Після цього власний обліковий запис секвенсера ініціює екстрене зняття, надаючи «доказ активів», стверджуючи, що він дійсно володіє активами на L2.
Очевидно, що через відсутність частини історії немає можливості безпосередньо довести, що джерело активів секвенсера є проблематичним. Попередні версії Плазми, такі як Plasma MVP, враховували це і встановлювали «пріоритет виведення». Якщо особа надасть підтвердження активу, що відповідає root, її запит на виведення коштів буде пріоритетним.
Якщо секвенсер обманює та ініціює виведення коштів під час надсилання кореневого номера 101, користувач може надати доказ активів, що відповідають кореневому номеру 99 або більш ранньому, щоб здійснити екстрене виведення. Очевидно, що до тих пір, поки секвенсор не може підробити історію, яка була опублікована на рівні 1, у користувача є спосіб втекти.
Але Плазма все ще має фатальну ваду: доки секвенсер ініціює приховування даних, людям доводиться покладатися на екстрене зняття коштів (також відоме як Exit Game) для забезпечення безпеки активів, і якщо велика кількість користувачів колективно знімає кошти за короткий проміжок часу, Рівень 1 буде простим у використанні;
Припустимо, хтось поповнює 100 ETH в LP-пул DEX, а потім секвенсор Плазми виходить з ладу або робить зло, і людям потрібно терміново виводити, в цей час 100 ETH користувача все ще контролюються контрактом DEX, хто повинен згадувати ці активи на рівні 1 в цей час?
Найкращий спосіб зробити це — дозволити користувачам спочатку викупити свої активи з пулу DEX, а потім дозволити користувачам самостійно виводити свої гроші на L1, але проблема полягає в тому, що секвенсор Плазми є несправним або пошкодженим, і користувачі не можуть викупити свої активи. Але чи не було б жахливо, якби ми дозволили власнику контракту DEX перевести активи, контрольовані контрактом, до L1, що, очевидно, давало власнику контракту право власності на активи, і він міг би в будь-який момент підняти ці активи до L1 і втекти?
Тож, врешті-решт, те, як поводитися з цією «державною власністю», що підтримується контрактами Defi, є величезним громом. **Якщо слідувати суспільному консенсусу, здається, що можна перебудувати дзеркальний контракт на рівні 1, який відображає контракт defi на рівні 2, але це створить досить величезні проблеми, збільшить альтернативну вартість, і хто проголосує за утилізацію дзеркального контракту, також буде великою проблемою. Це фактично пов'язано з проблемою розподілу публічної влади, про яку Сянма раніше говорив в інтерв'ю «Високопродуктивним публічним мережам важко робити нові речі, а смарт-контракти передбачають розподіл потужності.
Звичайно ж, Віталік також вказує на це у своїй нещодавній статті «Ігри на виході з валідіумів EVM: повернення Плазми» і виділяє це як один із факторів, що роблять Плазму недружньою до смарт-контрактів. **У минулому відомі варіанти Плазми, такі як Plasma MVP і Plasma Cash, використовували UTXO або подібні моделі для заміни моделі адреси облікового запису Ethereum і не підтримували смарт-контракти, що може уникнути проблеми «розподілу власності на активи», згаданої вище, хоча право власності на кожен UTXO належить користувачеві, але сам UTXO має багато недоліків і не є дружнім до смарт-контрактів. Тому рішення Plasma найкраще підходить для простого обміну платежами або книгами ордерів.
Пізніше, з популярністю ZK Rollup, сама Плазма також пішла зі сцени історії, оскільки у Rollup не було проблеми зі збереженням даних Плазми. Якщо секвенсер ZK Rollup запускає атаку на утримання даних і надсилає Stateroot до ланцюжка ETH лише без даних DA, такий root буде визнаний недійсним і відхилений контрактом Verifier на L1. Таким чином, дані DA, що відповідають юридичному Stateroot ZK Rollup, повинні бути доступні в ланцюжку ETH. Таким чином, не існує принципу «опублікувати тільки заголовок блоку або корінь merkle, але не відповідний тіло блоку», тобто можна вирішити проблему доступності даних/атаку на утримання даних. **
У той же час минулі дані DA Rollups доступні на Ethereum, і будь-хто може запустити вузли рівня 2 через історію ланцюжка ETH, що значно знижує складність децентралізованих або навіть інклюзивних схем секвенсорів. На противагу цьому, Плазма не має жорстких вимог до DA, і децентралізований секвенсер реалізувати складніше (щоб реалізувати замінний децентралізований секвенсор, ви повинні спочатку переконатися, що всі вузли L2 розпізнають один і той же блок, що висуває вимоги до реалізації DA).
Крім того, якщо секвенсор ZK Rollup спробує включити в блок Layer 2 недійсні транзакції, це не вдасться, що гарантується принципом доказу валідності.
Врешті-решт, секвенсер ZK Rollup має набагато менший простір для дій, ніж Плазма — у кращому випадку він може загальмувати оновлення Stateroot, бути еквівалентом простою на рівні UX або відхилити певні запити користувачів, що в просторіччі називають цензурою транзакцій. У той же час, якщо секвенсор вийде з ладу в схемі Rollup, іншим вузлам буде простіше його замінити. ** В ідеалі, ймовірність запуску режиму гри «Вихід» у Плазмі може бути зменшена до 0 (у ZK Rollup називається escape pod).
(Стовпець Proposer Failure на L2BEAT показує, як кожне рішення L2 може впоратися з помилками секвенсора, Self Pose часто відноситься до інших вузлів, які можуть замінити секвенсор, який в даний момент не працює)**
Сьогодні в екосистемі Ethereum майже немає команд, які б все ще дотримувалися маршруту Плазми, і майже всі проєкти Плазми є мертвонародженими.
(Віталік пояснює, чому ZK Rollup є кращим за Плазму, згадуючи інклюзивну роботу секвенсера та проблеми з DA)
Що таке Redstone: Це не Plasma, це варіант Optimium****
Вище ми коротко пояснили Плазму та причини, чому її замінено на Rollup, а що стосується Redstone, то ви, мабуть, також бачили різницю між нею та Плазмою: Redstone може розв'язати проблему атак на збереження даних** Наприклад, він не буде негайно випускати новий stateroot, а спочатку опублікує оригінальні дані DA поза мережею, а потім опублікує хеш даних DA в ланцюжку ETH як пов'язане зобов'язання облікових даних, заявивши, що він опублікував повні дані, що відповідають цьому хешу даних поза мережею.
(Офіційне пояснення Redstone власного плану щодо запобігання атакам на приховування даних)**
Будь-хто може кинути виклик секвенсеру Redstone, сказавши, що він не публікує необроблені дані для цього хешу даних поза мережею. На цьому етапі секвенсер повинен опублікувати дані, що відповідають хешу даних у ланцюжку, щоб відповісти на виклик запитувача. **Якщо секвенсер своєчасно не опублікує дані в ланцюжку ETH після оскарження, його раніше опублікований хеш/зобов'язання даних вважатиметься недійсним.
Якщо секвенсер своєчасно відповідає на запит претендента, він може вчасно отримати вихідні дані DA, що відповідають хешу даних. Зрештою, всі вузли L2 можуть отримати необхідні дані DA для вирішення проблеми атак на збереження даних. Звичайно, сам претендент повинен сплатити комісію, яка приблизно дорівнює вартості публікації секвенсором необроблених даних DA в ланцюжку ETH, щоб запобігти безкоштовній оскарженню секвенсером зловмисникам і завдати останньому збитків.
Нарешті, коли період виклику для datahash закінчиться, секвенсер опублікує відповідний rootroot, який є коренем, отриманим після виконання послідовності транзакцій, що міститься в даних DA, що відповідають хешу даних. На цьому етапі вузол L2 може використовувати систему доказів шахрайства, щоб оскаржити ці недійсні корені. Якщо секвенсер не публікує відповідні вихідні дані DA вчасно після оскарження хешу даних, секвенсер буде недійсним за замовчуванням, навіть якщо корінь стану, що відповідає хешу даних, буде опублікований пізніше.
Оскільки Redstone спочатку публікує дані DA, а потім публікує відповідний валідний Stateroot, він безпосередньо вирішує проблему атак приховування даних (секвенсор публікує лише root, але не дані DA).
Очевидно, що ця модель відрізняється від звичайного Optimium (OP Rollup of DA без Ethereum, наприклад Arbitrum Nova), Optimium зазвичай покладається на офчейн-комітети DAC для забезпечення доступності даних, DAC час від часу подає мульти-Sig txn у ланцюжок, а контракт Rollup на рівні 1 за замовчуванням буде виконуватися секвенсором, який випустив останню партію даних DA поза мережею після отримання мульти-Sig txn.
(图源:L2beat)
У той час як Metis і Arbitrum Nova подають Stateroot і datahash одночасно, якщо хтось вважає, що секвенсер приховує дані DA, він спробує запустити челендж, і секвенсер надішле дані DA, що відповідають хешу даних, в ланцюжок.
Таким чином, ключова відмінність між Redstone і Metis полягає в наступному: перший спочатку публікує datahash і чекає закінчення періоду виклику DA, перш ніж випустити stateroot, тоді як Metis публікує як stateroot, так і datahash, і якщо хтось ініціює челендж, дані DA завантажуються в ланцюжок. Очевидно, що рішення Redstone є безпечнішим, тому що за схемою Metis, якщо секвенсер не відповідає на запит претендента про дані DA, проблема атаки приховування даних не може бути швидко вирішена, і єдиний спосіб покластися на екстрене зняття та соціальний консенсус — дозволити іншим вузлам взяти на себе поточний секвенсор;
Однак, у випадку з Redstone, якщо секвенсер займається утриманням даних, випущений ним stateroot безпосередньо вважається недійсним, тому дані stateroot і DA зв'язуються, що дозволяє Redstone отримати гарантії DA, які ближче до Rollup, який, по суті, є кращим варіантом Optimium, ніж Arbitrum Nova і Metis.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Рестон: Це не плазма, а варіант Optimium
Автор: Фауст, гік web3***
Останнім часом гарячою темою став проект під назвою Redstone. **Цей об'єкт Layer2, запущений командою Lattice, був офіційно випущений 15 листопада і зараз запущений у тестовій мережі. Цікаво, що команда Lattice стверджує, що «Redstone — це ланцюг Alt-DA, натхненний плазмою».
Буквально за день до релізу Redstone Віталік опублікував статтю «Exit games for EVM validiums: the return of Plasma», в якій він коротко розглянув технічне рішення «Plasma», яке зникло з екосистеми Ethereum, і зазначив, що для вирішення проблеми Плазми можуть бути введені докази валідності (які плутають з ZK Proof).
У зв'язку з цим багато друзів вважають, що Віталік опублікував цю статтю для того, щоб дати Редстоуну платформу, і навіть у гік-спільноті Web3 деякі люди кажуть, що Віталік не інвестував у Redstone. У поєднанні з киплячою «суперечкою про визначення рівня 2 Ethereum» у попередніх чутках, широко поширена думка, що буде запущено наступне «відродження Плазми», і рішення DA за межами екосистеми Ethereum, такі як Celestia, можуть бути придушені, оскільки Plasma не має жорстких вимог до DA. **
Однак, згідно з дослідженням автора цієї статті, Редстоун не вписується в загальні рамки розчину Плазми, і його заява про те, що він «натхненний Плазмою», має можливість втерти жар статті Віталіка, а не те, що Віталік дійсно хоче відстоювати Редстоун. Крім того, виклик DA від Redstone схожий на проєкт рівня 2 Metis, запущений у квітні 2022 року, за винятком того, що порядок оновлення Stateroot та публікації даних DA відрізняється.
Отже, реальна ситуація полягає в тому, що ви, можливо, «надмірно інтерпретували» Редстоун. Нижче наведено просте пояснення того, як працює Плазма, чому вона не є дружньою до смарт-контрактів та DeFi, і що таке Redstone. **
Плазма: Термінове вилучення даних у разі атаки на приховування даних
Історію плазми можна простежити до буму Ethereum IC0 у 2017 році, коли попит на транзакції користувачів Ethereum різко зріс, а ETH з низьким TPS був перевантажений. На цьому етапі було випущено найранішу теоретичну версію Плазми, яка пропонувала схему масштабування рівня 2, яка могла б працювати з «майже всіма фінансовими сценаріями у світі».
Простіше кажучи, Плазма — це рішення для масштабування, яке публікує лише заголовок блоку рівня 2/корінь Меркла до рівня 1, а частина даних поза заголовком блоку/коренем Меркла (дані DA) публікується лише поза мережею. **Якщо кореневий каталог Меркла, опублікований секвенсером/оператором Плазми на L1, пов'язаний з некоректною транзакцією (наприклад, помилка цифрового підпису), користувач може надіслати сертифікат шахрайства, щоб довести, що кореневий каталог, надісланий секвенсером, пов'язаний із недійсною транзакцією.
Проблема полягає в тому, що для того, щоб видавати докази шахрайства, необхідно переконатися, що дані DA не приховуються, але Плазма не має жорстких вимог до рівня DA і не може гарантувати, що користувачі або вузли L2 зможуть отримувати дані. Якщо секвенсер запускає атаку приховування даних (також відому як проблема доступності даних) у певний момент часу і публікує лише новий заголовок блоку/корінь Меркла, але не публікує відповідне тіло блоку, що унеможливлює перевірку, чи дійсний заголовок/корінь блоку, користувач може лише за замовчуванням визнати секвенсор «безнадійним» і вивести активи з рівня 2 на рівень 1 через механізм аварійного виходу під назвою «Гра на виході».
Цей крок вимагає, щоб користувач надав доказ Меркла, щоб довести, що він має відповідну суму активів на L2, яку ми можемо назвати «Proof of Assets». Цікаво, що вихідна гра у Плазмі відрізняється від режиму Escape Pod у ZK Rollup, де користувачі ZK Rollup мають надсилати доказ Меркла, що відповідає найновішому коректному Stateroot, тоді як користувачі Плазми можуть надсилати докази, що відповідають кореневому коду Меркла, створеному давно.
Чому він так влаштований? Просто Stateroot, представлений ZK Rollup, буде негайно поставлений в суд контрактом на рівні 1 (щоб визначити, чи дійсний доказ дійсності). Якщо щойно поданий Stateroot є дійсним і легітимним, то користувач повинен надати доказ Меркла, що відповідає дійсному Stateroot, як доказ активів.
Втім, Корінь Меркла, надісланий секвенсором Плазми, контракт Layer1 не може судити про те, дійсний він чи ні, і може лише дозволити вузлу L2 взяти на себе ініціативу щодо виклику, щоб виключити недійсний Root, тому існуватиме механізм виклику, який робить роботу Плазми та Zk Rollup дуже різною. **
Припустимо, секвенсор тільки що випустив недійсний Merkle Root 101 і запустив атаку приховування даних, так що вузол L2 не може довести, що корінь 101 недійсний, тоді користувач може відправити доказ Меркла, що відповідає root 100 або більш ранньому root, і вивести свої активи.
Звичайно, тут є проблема, яку потрібно вирішити, тобто користувач може подати сертифікат активу, що відповідає root 30 або більш ранній, і запросити виведення активу на рівень 1, але статус активу цієї особи може змінитися після виходу root 30. Іншими словами, він подає застарілий доказ активів, що є типовою атакою подвійних витрат/подвійних витрат. **
У відповідь на це Plasma дозволяє будь-кому надати сертифікат про шахрайство для вищевказаних випадків, стверджуючи, що «доказ справедливості», наданий користувачем, який ініціював заяву про відкликання, є застарілим. Запровадивши принцип «будь-хто може оскаржити чужу інструкцію щодо виведення коштів», Плазмі не потрібно обробляти екстрені запити на виведення коштів, як ZK Rollup.
Але все ще існує ймовірність того, що сортувальник переведе чужі активи на власний обліковий запис L2, перш ніж запустити атаку на приховування даних, яка унеможливлює для сторонніх оскаржити їхнє шахрайство. Після цього власний обліковий запис секвенсера ініціює екстрене зняття, надаючи «доказ активів», стверджуючи, що він дійсно володіє активами на L2.
Очевидно, що через відсутність частини історії немає можливості безпосередньо довести, що джерело активів секвенсера є проблематичним. Попередні версії Плазми, такі як Plasma MVP, враховували це і встановлювали «пріоритет виведення». Якщо особа надасть підтвердження активу, що відповідає root, її запит на виведення коштів буде пріоритетним.
Якщо секвенсер обманює та ініціює виведення коштів під час надсилання кореневого номера 101, користувач може надати доказ активів, що відповідають кореневому номеру 99 або більш ранньому, щоб здійснити екстрене виведення. Очевидно, що до тих пір, поки секвенсор не може підробити історію, яка була опублікована на рівні 1, у користувача є спосіб втекти.
Але Плазма все ще має фатальну ваду: доки секвенсер ініціює приховування даних, людям доводиться покладатися на екстрене зняття коштів (також відоме як Exit Game) для забезпечення безпеки активів, і якщо велика кількість користувачів колективно знімає кошти за короткий проміжок часу, Рівень 1 буде простим у використанні;
Припустимо, хтось поповнює 100 ETH в LP-пул DEX, а потім секвенсор Плазми виходить з ладу або робить зло, і людям потрібно терміново виводити, в цей час 100 ETH користувача все ще контролюються контрактом DEX, хто повинен згадувати ці активи на рівні 1 в цей час?
Найкращий спосіб зробити це — дозволити користувачам спочатку викупити свої активи з пулу DEX, а потім дозволити користувачам самостійно виводити свої гроші на L1, але проблема полягає в тому, що секвенсор Плазми є несправним або пошкодженим, і користувачі не можуть викупити свої активи. Але чи не було б жахливо, якби ми дозволили власнику контракту DEX перевести активи, контрольовані контрактом, до L1, що, очевидно, давало власнику контракту право власності на активи, і він міг би в будь-який момент підняти ці активи до L1 і втекти?
Тож, врешті-решт, те, як поводитися з цією «державною власністю», що підтримується контрактами Defi, є величезним громом. **Якщо слідувати суспільному консенсусу, здається, що можна перебудувати дзеркальний контракт на рівні 1, який відображає контракт defi на рівні 2, але це створить досить величезні проблеми, збільшить альтернативну вартість, і хто проголосує за утилізацію дзеркального контракту, також буде великою проблемою. Це фактично пов'язано з проблемою розподілу публічної влади, про яку Сянма раніше говорив в інтерв'ю «Високопродуктивним публічним мережам важко робити нові речі, а смарт-контракти передбачають розподіл потужності.
Звичайно ж, Віталік також вказує на це у своїй нещодавній статті «Ігри на виході з валідіумів EVM: повернення Плазми» і виділяє це як один із факторів, що роблять Плазму недружньою до смарт-контрактів. **У минулому відомі варіанти Плазми, такі як Plasma MVP і Plasma Cash, використовували UTXO або подібні моделі для заміни моделі адреси облікового запису Ethereum і не підтримували смарт-контракти, що може уникнути проблеми «розподілу власності на активи», згаданої вище, хоча право власності на кожен UTXO належить користувачеві, але сам UTXO має багато недоліків і не є дружнім до смарт-контрактів. Тому рішення Plasma найкраще підходить для простого обміну платежами або книгами ордерів.
Пізніше, з популярністю ZK Rollup, сама Плазма також пішла зі сцени історії, оскільки у Rollup не було проблеми зі збереженням даних Плазми. Якщо секвенсер ZK Rollup запускає атаку на утримання даних і надсилає Stateroot до ланцюжка ETH лише без даних DA, такий root буде визнаний недійсним і відхилений контрактом Verifier на L1. Таким чином, дані DA, що відповідають юридичному Stateroot ZK Rollup, повинні бути доступні в ланцюжку ETH. Таким чином, не існує принципу «опублікувати тільки заголовок блоку або корінь merkle, але не відповідний тіло блоку», тобто можна вирішити проблему доступності даних/атаку на утримання даних. **
У той же час минулі дані DA Rollups доступні на Ethereum, і будь-хто може запустити вузли рівня 2 через історію ланцюжка ETH, що значно знижує складність децентралізованих або навіть інклюзивних схем секвенсорів. На противагу цьому, Плазма не має жорстких вимог до DA, і децентралізований секвенсер реалізувати складніше (щоб реалізувати замінний децентралізований секвенсор, ви повинні спочатку переконатися, що всі вузли L2 розпізнають один і той же блок, що висуває вимоги до реалізації DA).
Крім того, якщо секвенсор ZK Rollup спробує включити в блок Layer 2 недійсні транзакції, це не вдасться, що гарантується принципом доказу валідності.
Врешті-решт, секвенсер ZK Rollup має набагато менший простір для дій, ніж Плазма — у кращому випадку він може загальмувати оновлення Stateroot, бути еквівалентом простою на рівні UX або відхилити певні запити користувачів, що в просторіччі називають цензурою транзакцій. У той же час, якщо секвенсор вийде з ладу в схемі Rollup, іншим вузлам буде простіше його замінити. ** В ідеалі, ймовірність запуску режиму гри «Вихід» у Плазмі може бути зменшена до 0 (у ZK Rollup називається escape pod).
(Стовпець Proposer Failure на L2BEAT показує, як кожне рішення L2 може впоратися з помилками секвенсора, Self Pose часто відноситься до інших вузлів, які можуть замінити секвенсор, який в даний момент не працює)**
Сьогодні в екосистемі Ethereum майже немає команд, які б все ще дотримувалися маршруту Плазми, і майже всі проєкти Плазми є мертвонародженими.
(Віталік пояснює, чому ZK Rollup є кращим за Плазму, згадуючи інклюзивну роботу секвенсера та проблеми з DA)
Що таке Redstone: Це не Plasma, це варіант Optimium****
Вище ми коротко пояснили Плазму та причини, чому її замінено на Rollup, а що стосується Redstone, то ви, мабуть, також бачили різницю між нею та Плазмою: Redstone може розв'язати проблему атак на збереження даних** Наприклад, він не буде негайно випускати новий stateroot, а спочатку опублікує оригінальні дані DA поза мережею, а потім опублікує хеш даних DA в ланцюжку ETH як пов'язане зобов'язання облікових даних, заявивши, що він опублікував повні дані, що відповідають цьому хешу даних поза мережею.
(Офіційне пояснення Redstone власного плану щодо запобігання атакам на приховування даних)**
Будь-хто може кинути виклик секвенсеру Redstone, сказавши, що він не публікує необроблені дані для цього хешу даних поза мережею. На цьому етапі секвенсер повинен опублікувати дані, що відповідають хешу даних у ланцюжку, щоб відповісти на виклик запитувача. **Якщо секвенсер своєчасно не опублікує дані в ланцюжку ETH після оскарження, його раніше опублікований хеш/зобов'язання даних вважатиметься недійсним.
Якщо секвенсер своєчасно відповідає на запит претендента, він може вчасно отримати вихідні дані DA, що відповідають хешу даних. Зрештою, всі вузли L2 можуть отримати необхідні дані DA для вирішення проблеми атак на збереження даних. Звичайно, сам претендент повинен сплатити комісію, яка приблизно дорівнює вартості публікації секвенсором необроблених даних DA в ланцюжку ETH, щоб запобігти безкоштовній оскарженню секвенсером зловмисникам і завдати останньому збитків.
Нарешті, коли період виклику для datahash закінчиться, секвенсер опублікує відповідний rootroot, який є коренем, отриманим після виконання послідовності транзакцій, що міститься в даних DA, що відповідають хешу даних. На цьому етапі вузол L2 може використовувати систему доказів шахрайства, щоб оскаржити ці недійсні корені. Якщо секвенсер не публікує відповідні вихідні дані DA вчасно після оскарження хешу даних, секвенсер буде недійсним за замовчуванням, навіть якщо корінь стану, що відповідає хешу даних, буде опублікований пізніше.
Оскільки Redstone спочатку публікує дані DA, а потім публікує відповідний валідний Stateroot, він безпосередньо вирішує проблему атак приховування даних (секвенсор публікує лише root, але не дані DA).
Очевидно, що ця модель відрізняється від звичайного Optimium (OP Rollup of DA без Ethereum, наприклад Arbitrum Nova), Optimium зазвичай покладається на офчейн-комітети DAC для забезпечення доступності даних, DAC час від часу подає мульти-Sig txn у ланцюжок, а контракт Rollup на рівні 1 за замовчуванням буде виконуватися секвенсором, який випустив останню партію даних DA поза мережею після отримання мульти-Sig txn.
(图源:L2beat)
У той час як Metis і Arbitrum Nova подають Stateroot і datahash одночасно, якщо хтось вважає, що секвенсер приховує дані DA, він спробує запустити челендж, і секвенсер надішле дані DA, що відповідають хешу даних, в ланцюжок.
Таким чином, ключова відмінність між Redstone і Metis полягає в наступному: перший спочатку публікує datahash і чекає закінчення періоду виклику DA, перш ніж випустити stateroot, тоді як Metis публікує як stateroot, так і datahash, і якщо хтось ініціює челендж, дані DA завантажуються в ланцюжок. Очевидно, що рішення Redstone є безпечнішим, тому що за схемою Metis, якщо секвенсер не відповідає на запит претендента про дані DA, проблема атаки приховування даних не може бути швидко вирішена, і єдиний спосіб покластися на екстрене зняття та соціальний консенсус — дозволити іншим вузлам взяти на себе поточний секвенсор;
Однак, у випадку з Redstone, якщо секвенсер займається утриманням даних, випущений ним stateroot безпосередньо вважається недійсним, тому дані stateroot і DA зв'язуються, що дозволяє Redstone отримати гарантії DA, які ближче до Rollup, який, по суті, є кращим варіантом Optimium, ніж Arbitrum Nova і Metis.