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