Автор: Faust, geek web3
Что касается того, почему Plasma была похоронена в течение долгого времени, и почему Виталик будет решительно поддерживать Rollup, подсказки в основном указывают на два момента: реализация DA вне блокчейна в цепочке Ethereum ненадежна, а сокрытие данных легко происходит, а как только происходит сокрытие данных, трудно разработать доказательство мошенничества; ** Эти два момента делают Plasma в основном только UTXO или приблизительными моделями.
Чтобы понять эти два основных момента, давайте начнем с DA и хранения данных. DA расшифровывается как Data Aavailability (доступность данных), что буквально означает доступность данных, и в настоящее время многими людьми используется не по назначению, настолько, что его всерьез путают с «исторические данные могут быть проверены». Но на самом деле «исторические данные» и «доказательство хранения» — это давние проблемы, которые были решены такими компаниями, как Filecoin и Arweave. По данным Ethereum Foundation и Celestia, проблема DA связана исключительно со сценариями сокрытия данных. **
Дерево Меркла, корень Меркла и доказательство Меркла
Чтобы проиллюстрировать, что означают атаки с удержанием данных и проблемы DA, нам нужно сначала кратко поговорить о корне Меркла и дереве Меркла. ** В Ethereum или большинстве публичных цепочек древовидная структура данных, называемая деревом Меркла, используется для того, чтобы выступать в качестве сводки/каталога состояния всей учетной записи или для записи транзакций, упакованных в каждый блок.
**Конечный узел в нижней части дерева Меркла состоит из хэшей необработанных данных, таких как транзакции или состояние счета, **Эти хеши суммируются в пары и итерации, и, наконец, можно вычислить корень Меркла.
(Запись в нижней части диаграммы является исходным набором данных, соответствующим конечному узлу)
У корня Меркла есть свойство: если изменяется листовой узел в нижней части дерева Меркла, вычисляемый корень Меркла также изменится. Таким образом, деревья Меркла, соответствующие разным исходным наборам данных, будут иметь разные корни Меркла, точно так же, как у разных людей разные отпечатки пальцев. Технология проверки доказательств, известная как доказательство Меркла, использует это свойство дерева Меркла.
Например, если Ли Ган знает только значение корня Меркла на рисунке, он не знает, какие данные содержит полное дерево Меркла. Нам нужно доказать Ли Гану, что запись 3 действительно связана с корнем на картинке, или что хеш записи 3 существует на дереве Меркла, соответствующем корню.
Нам нужно только отправить Record3 и 3 блока дайджеста, помеченных серым цветом, Ли Гану, вместо того, чтобы фиксировать все дерево Меркла или все его листовые узлы, что является простотой доказательства Меркла. Если нижележащая запись дерева Меркла имеет большое количество листьев, например 2 в степени 2 блоков данных (около 1 миллиона), доказательство Меркла должно содержать не менее 21 блока данных.
(Блок данных 30 и H2 на рисунке могут представлять собой доказательство Меркла, доказывающее, что блок данных 30 существует на дереве Меркла, соответствующем H0)**
В Bitcoin, Ethereum или кроссчейн-мостах часто используется эта «простота» доказательства Меркла. Светлый узел, который мы знаем, на самом деле является вышеупомянутым Ли Ганом, который получает заголовок блока только от полного узла, а не от полного блока. Здесь важно подчеркнуть, что Ethereum использует дерево Меркла под названием State Trie, которое выступает в качестве сводки всего счета. Корень Меркла в State Trie, называемый StateRoot, изменяется при каждом изменении состояния одной из учетных записей, связанных с State Trie.
В заголовке блока Ethereum будет записан StateRoot, а также будет записан корень Меркла (называемый корнем Txn) дерева транзакций. Если блок 100 содержит 300 транзакций, то листья торгового дерева представляют эти 300 Txn.
Еще одно отличие заключается в том, что общий объем данных в State Trie особенно велик, а его базовый лист соответствует всем адресам в цепочке Ethereum (на самом деле существует множество устаревших хэшей состояния), поэтому исходный набор данных, соответствующий State Trie, не будет опубликован в блоке, в заголовке блока будет записан только StateRoot. Исходным набором данных дерева транзакций являются данные Txn в каждом блоке, а TxnRoot дерева будет записан в заголовке блока.
Поскольку легкий узел получает только заголовок блока, знает только StateRoot и TxnRoot и не может вывести полное дерево Меркла на основе корня (это определяется природой дерева Меркла и хеш-функции), легкий узел не может знать данные транзакции, содержащиеся в блоке, а также не знает, какие изменения произошли с учетной записью, соответствующей State Trie. **
Если Ван Цян хочет доказать легкому узлу (Ли Ган, упомянутый ранее), что блок 100 содержит некую транзакцию, и известно, что легкий узел знает заголовок блока 100 и знает TxnRoot, то приведенная выше задача переводится как: доказать, что этот Txn существует на дереве Меркла, соответствующем TxnRoot. В это время Ван Цяну нужно только представить соответствующее доказательство Меркла.
Во многих кроссчейн-мостах, основанных на легких клиентских решениях, часто используется легкость и простота легких узлов и упомянутого выше доказательства Меркла. Например, мосты ZK, такие как Map Protocol, настроят контракт в цепочке ETH для получения заголовков блоков из других цепочек (например, Polygon). Когда Relayer отправляет заголовок 100-го блока Polygon в контракт в цепочке ETH, контракт проверит валидность заголовка (например, достаточно ли у него подписей от 2/3 POS-узлов в сети Polygon).
Если заголовок действителен и пользователь заявляет, что он инициировал кроссчейн Txn из Polygon в ETH, Txn упаковывается в 100-й блок Polygon. Ему нужно только доказать с помощью доказательства Меркла, что инициированный им кроссчейн Txn может соответствовать TxnRoot заголовка блока 100 (другими словами, он доказывает, что инициированный им кроссчейн Txn имеет запись в блоке 100 Polygon). Тем не менее, мост ZK будет использовать доказательства с нулевым разглашением для сжатия объема вычислений, необходимых для проверки доказательства Меркла, что еще больше снизит стоимость проверки контрактов кроссчейн-моста.
Проблемы с DA и атаками на хранение данных
После разговора о дереве Меркла, корне Меркла и доказательстве Меркла, давайте вернемся к проблеме атаки DA и удержания данных, упомянутой в начале статьи, которая была исследована до 2017 года, и в оригинальной статье Celestia археологизировалось происхождение проблемы DA. В документе 2017~18 года сам Виталик рассказывал о том, как блокировщики могут намеренно скрывать определенные фрагменты данных блока и публиковать неполные блоки, чтобы полные узлы не могли подтвердить правильность выполнения транзакций/переходов состояний.
В этот момент блок-продюсер может украсть активы пользователя, например, перевести все монеты на счете A на другой адрес, а полный узел не может определить, сделал ли это сам А, потому что он не знает полных данных транзакции, содержащихся в последнем блоке.
В публичных цепочках уровня 1, таких как Bitcoin или Ethereum, честные полные узлы будут напрямую отклонять вышеуказанные недействительные блоки. Но легкие узлы отличаются тем, что они получают только заголовок блока из сети, они знают только StateRoot и TxnRoot, и они не знают, является ли исходный блок, соответствующий заголовку и двум корням, валидным.
В белой книге Биткоина на самом деле есть мозговая дыра для этой ситуации, Сатоши Накамото когда-то считал, что большинство пользователей будут склонны запускать легкие узлы с более низкими требованиями к конфигурации, а легкие узлы не могут судить, является ли блок, соответствующий заголовку блока, валидным, и если блок невалидный, честный полный узел отправит сигнал тревоги легкому узлу.
Но Сатоши Накамото не стал делать более детальный анализ этого решения, и позже Виталик и основатель Celestia Мустафа развили эту идею, в сочетании с работами других предшественников, чтобы внедрить выборку данных DA, чтобы гарантировать, что честные полные узлы могут восстанавливать полные данные каждого блока и поднимать тревогу при необходимости.
Примечание: DA Data Sampling (DAS) и Celestia не являются фокусом этой статьи, заинтересованные читатели могут прочитать предыдущую статью Geek Web3: «Заблуждения о доступности данных: DA= публикация данных ≠ извлечение исторических данных»
Защита Plasma от мошенничества
Проще говоря, Plasma — это решение для масштабирования, которое публикует только заголовки блоков уровня 2 на уровне 1, а данные DA за пределами заголовка блока (полный набор данных о транзакциях/изменение состояния для каждой учетной записи) публикуются только вне сети. Другими словами, Plasma похожа на кроссчейн-мост, основанный на легких клиентах, реализуя легкий клиент уровня 2 с контрактом в цепочке ETH, и когда пользователь заявляет, что хочет перевести активы из L2 в L1, он должен представить доказательство Меркла, чтобы доказать, что он действительно владеет активами.
** Логика верификации для активов от L2 до L1 аналогична упомянутому выше мосту ZK, за исключением того, что модель моста Plasma основана на доказательствах мошенничества, а не на доказательствах ZK, что ближе к так называемому «оптимистичному мосту». **Запросы на вывод средств с L2 на L1 в сети Plasma выпускаются не сразу, а имеют «период вызова», так как о цели периода вызова мы объясним ниже.
У Plasma нет строгих требований к выпуску данных/DA, секвенсор/оператор просто транслирует каждый L2-блок вне блокчейна, а узлы, которые хотят получить L2-блок, делают это самостоятельно. После этого секвенсор опубликует заголовок блока L2 в Layer 1. Например, секвенсор транслирует блок 100 вне сети, а затем публикует заголовок блока в блокчейне. Если блок 100 содержит недействительные транзакции, любой плазменный узел может предоставить доказательство Меркла контракту на ETH до окончания «периода оспаривания», чтобы доказать, что заголовок блока 100 может быть связан с недействительной транзакцией, что является сценарием, охватываемым доказательствами мошенничества.
Примеры использования Plasma для защиты от мошенничества также включают следующее:
- Предположим, что прогресс сети Plasma достигает блока 200, и пользователь A инициирует заявление о выводе, говоря, что у него есть 10 ETH в блоке 100. Но на самом деле пользователь А потратил ETH на аккаунте после блока 100.
Таким образом, поведение А на самом деле заключается в том, чтобы потратить 10 ETH, заявить, что у него было 10 ETH в прошлом, и попытаться вывести ETH. Это классический «двойной вывод», двойная трата. В настоящее время любой желающий может предоставить доказательство Меркла, чтобы доказать последний статус активов пользователя А, и не соответствует его заявлению о выводе средств, то есть доказать, что у А не было выписки о выводе средств после блока 100 (различные схемы Plasma имеют непоследовательные методы доказательства для этой ситуации, и модель адреса счета гораздо более проблематична, чем доказательство двойного расходования UTXO).
- Если это схема Plasma, основанная на модели UTXO (что в основном было в прошлом), то в заголовке блока нет StateRoot, только TxnRoot (UTXO не поддерживает модель адресов учетных записей в стиле Ethereum, а также не имеет глобального дизайна состояния, как State Trie). Другими словами, цепочка, использующая модель UTXO, имеет только записи транзакций, а не записи состояния.
В этом случае секвенсор сам может запустить атаку двойного расходования, например, потратить уже потраченные UTXO или выдать пользователю дополнительные UTXO из воздуха. Любой пользователь может предоставить доказательство Меркла, чтобы доказать, что история использования UTXO появлялась (была потрачена) в предыдущих блоках, или доказать, что историческое происхождение UTXO сомнительно. **
- Для EVM-совместимых/State-Trie-enabled Plasma схем секвенсор может отправить недопустимый StateRoot, например, после выполнения транзакции, содержащейся в блоке 100, StateRoot должен быть преобразован в ST+, но секвенсор отправляет ST- в Layer 1.
В этом случае доказательство мошенничества более сложное и требует, чтобы транзакция в блоке 100 была воспроизведена в цепочке Ethereum, что потребляет много газа при требуемом объеме вычислений и входных параметров. Командам, начинающим внедрять Plasma, трудно достичь таких сложных доказательств мошенничества, поэтому большинство из них используют модель UTXO, в конце концов, доказательства мошенничества на основе UTXO очень просты и легко реализуются (Fuel, первая схема Rollup для запуска доказательств мошенничества, основана на UTXO)
Хранение данных и выход из игры****
Конечно, вышеупомянутые сценарии, в которых доказательства мошенничества могут вступить в силу, устанавливаются только в том случае, если DA/релиз данных действителен. Если секвенсор утаит данные и не опубликует полный блок вне блокчейна, узел Plasma не сможет подтвердить, является ли заголовок блока на уровне 1 действительным, и, конечно же, он не сможет без проблем опубликовать доказательство мошенничества.
В это время секвенсор может украсть активы пользователя, например, перевести все монеты со счета А на счет Б, затем перевести деньги со счета Б на счет С и, наконец, инициировать вывод средств от имени С. Учетные записи B и C принадлежат секвенсору, и передача B->C безвредна, даже если она обнародована.** Но секвенсор может утаить данные о недействительной передаче A->B, и люди не могут доказать, что существует проблема с источником активов B и C** (чтобы доказать, что источник активов B проблематичен, необходимо указать, что цифровая подпись «определенный Txn, переданный B» неверна).
Решение Plasma на основе UTXO нацелено на тот факт, что любой, кто инициирует вывод средств, должен предоставить полную историю актива, хотя позже появятся и другие улучшения. Однако, если это EVM-совместимое решение Plasma, оно будет слабым в этой области. Потому что, если будет задействован Txn, связанный с контрактом, это повлечет за собой огромные затраты на проверку процесса перехода состояния в цепочке, поэтому трудно реализовать схему проверки действительности вывода средств, поддерживая модель адреса учетной записи и смарт-контракт Plasma.
Кроме того, помимо темы выше, независимо от того, идет ли речь о Plasma на основе UTXO или модели адресов учетных записей, удержание данных может вызвать панику, поскольку вы не знаете, какие транзакции выполняет секвенсор. ** Узлы Plasma обнаружат, что что-то не так, но они не смогут опубликовать доказательства мошенничества, потому что секвенатор Plasma не отправит данные, необходимые для доказательства мошенничества.
В настоящее время люди могут видеть только соответствующий заголовок блока, но они не знают, что находится в блоке, и они не знают, во что превратились активы их учетной записи, поэтому они коллективно инициируют заявление о выводе средств и пытаются вывести средства с доказательством Меркла, соответствующим историческому блоку, ** запуская экстремальный сценарий под названием «Exit Game», который приведет к «паническому бегству», что приведет к серьезной перегрузке уровня 1 и все равно приведет к повреждению активов некоторых людей** (Люди, которые не получают честных уведомлений от узлов или не проводят пальцем по Twitter, не будут знать, что секвенсор крадет монеты.)
Таким образом, Plasma является ненадежным решением для масштабирования уровня 2, и как только происходит атака с удержанием данных, она запускает «Exit Game», в результате чего пользователи могут легко понести убытки, что является основной причиной отказа от нее. **
Причины, по которым plasma сложно поддерживать смарт-контракты****
После разговора о проблемах с Exit Game и хранением данных, давайте рассмотрим, почему Plasma сложно поддерживать смарт-контракты, в основном по двум причинам:
Во-первых, если это актив контракта Defi, кто должен выводить его на уровень 1? Поскольку это, по сути, перенос состояния контракта с уровня 2 на уровень 1, предположим, что кто-то взимает 100 ETH в пул LP DEX, а затем секвенсор Plasma делает зло, и люди хотят срочно вывести, в это время 100 ETH пользователя все еще контролируются контрактом DEX, кто должен упоминать эти активы на уровне 1 в это время?
Кажется, что лучший способ сделать это — позволить пользователю сначала выкупить активы с DEX, а затем он сам выведет деньги на L1, но проблема в том, что секвенсор Plasma сделал что-то плохое и может отклонить запрос пользователя в любое время.
Итак, что, если мы заранее настроим владельца для контракта DEX, что позволит ему в случае чрезвычайной ситуации поставить активы контракта на L1? Очевидно, что это даст владельцу контракта право собственности на публичные активы, и он может в любой момент поставить эти активы на L1 и сбежать, разве это не ужасно?
Очевидно, что делать с этой «общественной собственностью», в которой доминируют контракты Defi, — это огромный гром. ** На самом деле это связано с проблемой распределения публичной власти, о которой Сянма ранее говорил в интервью с «Высокопроизводительным публичным сетям трудно делать что-то новое, а смарт-контракты предполагают распределение власти».
Во-вторых, если контракту не будет позволено перенести свое состояние, он понесет огромные потери, а если контракту будет разрешено перенести свое состояние на уровень 1, произойдет двойной вывод средств, который трудно решить с помощью защиты от мошенничества Plasma:
Например, предположим, что Plasma использует модель адресов счетов Ethereum, поддерживает смарт-контракты, имеет микшер монет, в настоящее время вносит 100 ETH, а владелец миксера монет контролируется Бобом;
Допустим, Боб выводит 50 ETH из миксера на блоке 100. После этого Боб инициировал заявление о выводе средств и пересек 50 ETH до уровня 1;
После этого Боб использует снимок прошлого состояния контракта (например, блок 70) для переноса прошлого состояния микшера на уровень 1, который также пересечет 100 ETH, которые «когда-то» были у микшера, на уровень 1.
Очевидно, что это типичная «двойная просадка», то есть двойная трата. ** 150 ETH было упомянуто Бобом для Layer 1, но пользователи сети Layer 2 заплатили только 100 ETH микшеру/Бобу, а 50 ETH были выведены из воздуха. Это может легко истощить запасы плазмы**. Теоретически можно было бы инициировать доказательство мошенничества, чтобы доказать, что состояние контракта на миксер изменилось после блока 70.
Но если вы хотите продемонстрировать доказательства того, что контракт Mixer изменился после блока 70, вы должны запустить все упомянутые выше Txn в цепочке Ethereum, чтобы, наконец, позволить контракту Plasma определить, что состояние контракта Mixer действительно изменилось (причина, по которой он такой сложный, определяется структурой самой Plasma). Если сумма Txn настолько велика, доказательство мошенничества вообще не будет опубликовано на Layer 1 (оно превысит лимит газа для одного блока Ethereum).
Теоретически, в приведенном выше сценарии двойного расходования кажется, что вам нужно только отправить снимок текущего состояния микшера (что на самом деле является доказательством Меркла, соответствующим StateRoot), но на самом деле, поскольку Plasma не публикует данные о транзакциях в цепочке, контракт не может определить, является ли снимок состояния, который вы отправляете, действительным. ** Это связано с тем, что секвенсор сам может инициировать хранение данных, отправлять недопустимые снимки состояния и злонамеренно указывать на любое изъятие. **
Например, когда вы объявляете, что у вас есть 50 ETH на вашем счете, и инициируете вывод средств, секвенсор может в частном порядке очистить вашу учетную запись до 0, а затем инициировать удержание данных, отправить недействительный StateRoot в цепочку и отправить соответствующий снимок состояния, чтобы ложно обвинить вас в том, что у вас закончились деньги на вашем счете. На этом этапе вы не можете доказать, что StateRoot и State Snapshot, отправленные секвенсором, являются недействительными, потому что он инициировал хранение данных, и вы не получаете достаточно данных, необходимых для доказательства мошенничества. **
Чтобы предотвратить это, узел Plasma также воспроизводит историю транзакций в течение этого периода, представляя моментальный снимок состояния, чтобы доказать, что кто-то потратил дважды, что не позволяет секвенсору удерживать данные, чтобы предотвратить вывод средств другими. В Rollup, если вы столкнетесь с вышеупомянутым двойным выводом, вам не нужно переигрывать историческую транзакцию в теории, потому что Rollup не имеет проблемы удержания данных и будет «заставлять» секвенсор публиковать данные DA в цепочке. ** Секвенсоры свертки, отправляющие недопустимый снимок состояния StateRoot-state, либо не пройдут проверку контракта (ZK Rollup), либо вскоре будут оспорены (OP Rollup).
На самом деле, в дополнение к примеру с миксером монет, упомянутым выше, такие сценарии, как контракты с мультиподписью, также могут привести к двойному выводу средств в сети Plasma. Доказательства мошенничества неэффективны в таких сценариях. **Данная ситуация анализируется в ETH Research.
Подводя итог, можно сказать, что из-за того, что схема Plasma не способствует смарт-контрактам и в основном не поддерживает миграцию состояния контракта на уровень 1, мейнстрим Plasma должен выбрать UTXO или аналогичные механизмы, потому что UTXO не имеет проблемы конфликта прав собственности на активы и может хорошо поддерживать защиту от мошенничества (намного меньше по размеру), но за счет одного сценария приложения она может в основном поддерживать только передачу или обмен книгой ордеров.
Кроме того, поскольку само доказательство мошенничества сильно зависит от данных DA, будет трудно создать эффективную систему защиты от мошенничества, если уровень DA ненадежен. Тем не менее, Plasma слишком примитивна, чтобы решить проблему атак с удержанием данных, и с появлением Rollup Plasma медленно исчезла из истории. **
