По поводу того, почему Plasma долгое время находилась в тени, и почему Виталик настоятельно поддерживает Rollup, улики в основном указывают на два момента: внедрение DA под цепочку Ethereum ненадежно, и удержание данных легко происходит. При возникновении удержания данных доказательство мошенничества сложно проводить; Сам дизайн механизма Plasma крайне недружелюбен к смарт-контрактам, и особенно сложно поддерживать миграцию статуса контракта на уровень 1. Эти два момента делают Plasma практически единственным использованием моделей UTXO или аналогичных.

Для понимания вышеупомянутых двух ключевых моментов давайте начнем с проблем DA и удержания данных. Полное название DA - это доступность данных, что в переводе буквально означает доступность данных. Сейчас многими людьми это слово злоупотребляется настолько сильно, что серьезно путается с "можно проверить исторические данные". Но на самом деле "можно проверить исторические данные" и "доказательство хранения" - это проблемы, которые уже решили Filecoin и Arweave. По мнению Ethereum Foundation и Celestia, проблема DA чисто исследует сценарии удержания данных.

Дерево Меркля, Корень Меркля и Доказательство Меркля

Для объяснения того, что на самом деле означают атаки с удержанием данных и проблемы с DA, нам нужно кратко поговорить сначала о Меркл-корне и Меркл-дереве. В Ethereum или большинстве общедоступных цепочек используется древовидная структура данных, называемая Меркл-деревом, чтобы служить сводкой/каталогом состояния всех счетов или записывать транзакции, упакованные в каждом блоке.

Листовой узел внизу дерева Меркля состоит из хэшей исходных данных, таких как транзакции или состояние счета. Эти хэши суммируются попарно и повторяются итеративно, и, наконец, можно вычислить корень Меркля.

(Запись в нижней части рисунка является исходным набором данных, соответствующим конечному узлу)Корень Меркла имеет свойство:Если изменяется листовой узел в нижней части дерева Меркла, вычисленный корень Меркла также изменится. Таким образом, деревья Меркла, соответствующие разным исходным наборам данных, будут иметь разные корни Меркла, точно так же, как у разных людей разные отпечатки пальцев. Технология проверки доказательств под названием Merkle Proof использует это свойство дерева Меркла. Возьмем в качестве примера приведенный выше рисунок, если Ли Ган знает только значение корня Меркла на картинке, он не знает, какие данные содержит полное дерево Меркла. Мы хотим доказать Ли Гану, что Запись 3 действительно связана с Корнем на картинке, или, другими словами, доказать, что хеш Записи 3 существует на дереве Меркла, соответствующем Корню. Нам нужно только отправить Record3 и три блока данных дайджеста, отмеченные серым цветом, Ли Гану, без необходимости отправлять все дерево Меркла или все его листовые узлы. В этом и заключается простота доказательства Меркла.Когда базовые записи дерева Меркла содержат очень много листьев, например, оно содержит 2 блока данных в 20-й степени (примерно 1 миллион), доказательство Меркла должно содержать не менее 21 блока данных.

(Блок данных 30 и H2 на рисунке могут представлять собой доказательство Меркла, доказывающее, что блок данных 30 существует на дереве Меркла, соответствующем H0)Эта «простота» доказательства Меркла часто используется в Bitcoin, Ethereum или кроссчейн-мостах. Световой узел, который мы знаем, на самом деле является Ли Ганом, упомянутым выше. Он получает заголовок блока только от полного узла, а не от полного блока. Здесь необходимо подчеркнуть, что Ethereum использует дерево Меркла под названием State Trie, которое служит сводкой всех счетов. До тех пор, пока изменяется состояние учетной записи, связанной с Trie состояния, корень Меркла Trie состояния, называемый StateRoot, будет изменяться. В заголовке блока Ethereum будет записан StateRoot, а также будет записан корень Меркла дерева транзакций (называемый корнем Txn), одно из различий между деревом транзакций и деревом состояний заключается в том, что данные, представленные нижележащими листьями, отличаются. Если блок No100 содержит 300 транзакций, то листья дерева транзакций представляют эти 300 Txn. Еще одно отличие заключается в том, что общий объем данных State Trie чрезвычайно велик. Его нижние листья соответствуют всем адресам в цепочке Ethereum (на самом деле существует множество устаревших хэшей состояний), поэтому исходный набор данных, соответствующий State Trie, не будет выпущен. В блоке в заголовке блока записывается только StateRoot. Исходным набором данных дерева транзакций являются данные Txn в каждом блоке, а TxnRoot этого дерева будет записан в заголовок блока.

Поскольку легкий узел получает только заголовок блока и знает только StateRoot и TxnRoot, он не может вывести полное дерево Меркля на основе корня (это определяется свойствами дерева Меркля и хеш-функции), поэтому легкие узлы не могут знать данные транзакции, содержащиеся в блоке, и не знают, какие изменения произошли в учетной записи, соответствующей State Trie. Если Ван Цян хочет доказать легкому узлу (о котором упоминал Ли Ганг ранее), что блок № 100 содержит определенную транзакцию, и известно, что легкий узел знает заголовок блока № 100 и знает TxnRoot, то вышеуказанная проблема превращается в: доказать, что данная транзакция существует в соответствующем дереве Меркля для TxnRoot. В этот момент Ван Цяну нужно только представить соответствующее доказательство Меркля.

Во многих кроссчейн-мостах, основанных на легких клиентских решениях, часто используется легкий вес и простота легких узлов и упомянутого выше доказательства Меркла. Например, мосты ZK, такие как Map Protocol, настроят контракт в цепочке ETH специально для получения заголовков блоков из других цепочек (например, Polygon). Когда Ретранслятор передаст заголовок 100-го блока Polygon контракту в цепочке ETH, контракт проверит валидность заголовка (например, собрал ли он подписи 2/3 POS-узлов в сети Polygon). Если заголовок действителен и пользователь заявляет, что он инициировал кроссчейн Txn из Polygon в ETH, Txn будет упакован в 100-й блок Polygon. Ему нужно только использовать Merkle Proof, чтобы доказать, что инициированный им кроссчейн Txn может соответствовать TxnRoot в заголовке блока No100 (другими словами, это доказать, что инициированный вами кроссчейн Txn записан в блоке Polygon 100.). Тем не менее, ZK Bridge будет использовать доказательство с нулевым разглашением для сжатия суммы расчета, необходимой для проверки доказательства Меркла, что еще больше снизит стоимость проверки контрактов кроссчейн-моста.

Проблемы с DA и атакой на удержание данных

После обсуждения Merkle Tree, Merkle Root и Merkle Proof вернемся к проблеме DA и атакам на удержание данных, упомянутым в начале статьи. Эта проблема была обсуждена еще в 2017 году. Исходная статья Celestia имеет источник проблемы DA. Виталик сам упоминал в документе с 2017 по 2018 год, что производитель блока может умышленно скрывать определенные фрагменты данных блока и распространять неполные блоки наружу. В результате полный узел не может подтвердить правильность выполнения транзакции/перехода состояния.

На данный момент блок-продюсер может украсть активы пользователя, например, перевести все монеты счета A на другие адреса, но полный узел не может определить, сделал ли это сам A, потому что он не знает полную транзакцию, включенную в последний блок. данные.

На общедоступных цепях уровня 1, таких как Bitcoin или Ethereum, честные полные узлы будут непосредственно отклонять вышеуказанные недопустимые блоки. Но легкие узлы отличаются. Они получают только заголовки блоков из сети. Мы знаем только StateRoot и TxnRoot, но мы не знаем, являются ли заголовок и первоначальные блоки, соответствующие этим двум корням, действительными.

В Биткоинской белой книге фактически есть некоторые размышления по этому поводу. Сатоши Накамото когда-то считал, что большинство пользователей будут склонны запускать легкие узлы с более низкими требованиями к конфигурации, и легкие узлы не могут определить, является ли блок, соответствующий заголовку блока, действительным. Если блок недействителен, честные полные узлы отправят предупреждение легким узлам.

Однако Сатоши Накамото не проводил более детального анализа этого решения. Позже Виталик и основатель Celestia Мустафа объединили эту идею с результатами других предшественников и ввели выборку данных DA, чтобы гарантировать, что честные полные узлы могут восстановить каждую область. блок полных данных и генерировать предупреждения при необходимости.

Примечание: DA Data Sampling (DAS) и Celestia не являются центральной темой этой статьи. Заинтересованные читатели могут прочитать предыдущие статьи “Geek Web3”:«Недопонимание доступности данных: DA = Выпуск данных ≠ Получение исторических данных»

Доказательство мошенничества в плазме

Проще говоря, Plasma - это решение для расширения, которое публикует только заголовок блока Layer2 на Layer1, а данные DA вне заголовка блока (полный набор данных транзакций/изменений статуса каждого аккаунта) выпускаются только вне цепочки. Другими словами, Plasma похожа на межцепочный мост на основе легких клиентов. Она использует контракты для реализации легких клиентов Layer 2 на цепочке ETH. Когда пользователи объявляют, что они хотят перевести активы с L2 на L1, они должны представить доказательство Меркля, чтобы доказать, что они владеют этими активами. Логика верификации перевода активов с L2 на L1 аналогична упомянутому выше мосту ZK, за исключением того, что модель моста Plasma основана на доказательстве мошенничества, а не ZK-доказательстве, и ближе к так называемому «оптимистичному мосту». Запросы на вывод с L2 на L1 в сети Plasma не будут выпущены немедленно, но будет "период вызова". Что касается цели периода вызова, мы объясним ниже.

Plasma не предъявляет строгих требований к выпуску данных/DA. Секвенсор/оператор транслирует только каждый блок L2 вне блокчейна, и узлы, которые хотят получить блоки L2, могут получить его самостоятельно. После этого сортировщик опубликует заголовок блока L2 в Layer1. Например, секвенсор сначала транслирует блок No100 вне блокчейна, а затем публикует заголовок блока в цепочку. Если блок 100 содержит невалидные транзакции, любой узел Plasma может отправить Merkle Proof в контракт на ETH до окончания «периода вызова». Докажите, что заголовок блока No 100 может быть связан с недействительной транзакцией, на этот сценарий распространяется защита от мошенничества.

Сценарии применения Plasma для защиты от мошенничества также включают в себя следующее:1. Предположим, что прогресс сети Plasma доходит до блока No200. В это время пользователь А инициирует заявление о выводе средств, сообщая, что когда он был в блоке No100, у него было 10 ETH. Но на самом деле пользователь А потратил ETH на своем счете после блока 100. Поэтому поведение А на самом деле такое: потратив 10 ETH, он заявляет, что в прошлом у него было 10 ETH, и пытается вывести эти ETH. Это типичный «двойной вывод» и двойные траты. В настоящее время любой желающий может представить доказательство Меркла, чтобы доказать, что последнее состояние активов пользователя А не удовлетворяет его заявлению о выводе средств, то есть доказать, что А не снял деньги, заявленные после блока 100. (Различные схемы Plasma имеют несогласованные методы доказательства для этой ситуации, и модель адреса счета гораздо более проблематична, чем доказательство двойного расходования UTXO). 2. Если это решение Plasma, основанное на модели UTXO (в основном так было в прошлом), заголовок блока не содержит StateRoot, только TxnRoot (UTXO не поддерживает модель адресов учетных записей в стиле Ethereum, и нет дизайна глобального состояния, такого как State Trie). Другими словами, цепочка, использующая модель UTXO, имеет только записи транзакций и не содержит записей о состоянии. В это время сам секвенсор может запустить атаку двойного расходования, например, потратить UTXO, который был потрачен снова, или выдать пользователю дополнительный UTXO из воздуха. Любой пользователь может предоставить доказательство Меркла, чтобы доказать, что запись об использовании UTXO появлялась (была потрачена) в прошлых блоках, или доказать, что существует проблема с историческим источником определенного UTXO.

1. Для совместимых с EVM/поддерживаемых деревом состояний решений Plasma сортировщик может отправить недопустимый StateRoot. Например, после выполнения транзакции, содержащейся в 100-м блоке, StateRoot должен быть преобразован в ST+, но сортировщик переходит на Layer1. То, что было отправлено, было ST-. Доказательство мошенничества в этом случае более сложное и требует повторного выполнения транзакции в блоке № 100 на цепочке Ethereum. Расчетная сумма и необходимые входные параметры потребуют много газа. Команды, которые рано приняли Plasma, испытали трудности с достижением таких сложных доказательств мошенничества, поэтому большинство из них приняли модель UTXO. В конце концов, доказательства мошенничества на основе UTXO просты и легко реализуются. (Fuel, первое решение rollup, предоставляющее доказательство мошенничества, основано на UTXO)

Удержание данных и игра на выходе. Конечно, вышеупомянутые сценарии, в которых доказательство мошенничества может быть эффективным, устанавливаются только в том случае, если DA/выпуск данных эффективен. Если последователь уделяет внимание удержанию данных и не публикует полные блоки вне цепи, узел Plasma не сможет подтвердить, является ли заголовок блока на уровне 1 действительным, и, конечно, не сможет плавно выдавать доказательства мошенничества.

На этом этапе секвенсор может украсть активы пользователя, например, в частном порядке перевести все монеты со счета А на счет Б, затем перевести деньги со счета Б на счет С и, наконец, инициировать вывод средств от имени С. Учетные записи Б и С принадлежат самому секвенсору. Даже если передача B->C будет обнародована, она не причинит никакого вреда; Но сортировщик может утаить данные о недействительном переводе A->B, и люди не смогут доказать, что есть проблема с источником активов B и C. (Чтобы доказать, что источник активов B является подозрительным, необходимо указать, что цифровая подпись «определенный Txn, переданный B» неверна). Решение Plasma на базе UTXO имеет целевые меры. Например, когда кто-либо инициирует вывод средств, он должен предоставить все исторические источники активов. Конечно, позже будут приняты дополнительные меры по улучшению. Но если это EVM-совместимое решение Plasma, оно будет выглядеть слабым в этой области. Потому что, если задействован Txn, связанный с контрактом, проверка процесса перехода состояния в цепочке повлечет за собой огромные затраты, поэтому Plasma, которая поддерживает модели адресов учетных записей и смарт-контракты, не может легко реализовать схему проверки действительности вывода средств. Кроме того, помимо вышеупомянутой темы, будь то Plasma на основе UTXO или модель адресов учетных записей, как только произойдет удержание данных, это в основном вызовет панику у людей, потому что вы не знаете, какие транзакции выполнил секвенсор. Узлы Plasma обнаружат, что что-то не так, но они не смогут предоставить доказательства мошенничества, потому что секвенатор Plasma не выдал данные, необходимые для защиты от мошенничества. В настоящее время пользователи могут видеть только заголовок соответствующего блока, но они не знают, что находится в блоке и что стало с активами их аккаунта. Каждый коллективно инициирует заявление о выводе средств и использует соответствующий заголовок блока. Merkle Proof пытается вывести деньги,Запуская экстремальный сценарий под названием «Exit Game», эта ситуация приведет к «паническому бегству», вызвав серьезную перегрузку на уровне 1, и все равно приведет к повреждению активов некоторых людей. (Люди, которые не получали честных уведомлений от ноды или не проверяли Twitter, не будут знать, что секвенсор крадет монеты).

Таким образом, Plasma является ненадежным решением для расширения уровня 2. Как только произойдет атака с удержанием данных, будет запущена «Exit Game», что может легко привести к убыткам пользователей. Это основная причина отказа от него. Почему Plasma испытывает трудности с поддержкой смарт-контрактовПосле разговора о выходе из игры и проблемах с хранением данных, давайте рассмотрим, почему Plasma испытывает трудности с поддержкой смарт-контрактов. Есть две основные причины: во-первых, если это актив контракта Defi, кто должен выводить его на уровень 1? Потому что это, по сути, перенос статуса контракта с Layer2 на Layer1.Предположим, кто-то вносит 100 ETH в пул DEX LP, а затем секвенсор Plasma делает что-то плохое, и люди хотят срочно вывести деньги. В это время 100 ETH пользователя по-прежнему контролируются контрактом DEX. Кто должен владеть этими активами в настоящее время? Упоминается на уровне 1? Лучший способ, по-видимому, заключается в том, чтобы позволить пользователям сначала выкупить активы с DEX, а затем позволить пользователям самим переводить деньги на L1. Но проблема в том, что сортировщик Plasma натворил зло и может в любой момент отклонить запросы пользователей. Итак, что, если мы заранее настроим Владельца для контракта DEX и позволим ему поднять активы контракта до L1 в чрезвычайной ситуации? Очевидно, что это даст владельцу контракта право собственности на государственные активы. Он может поднять эти активы до L1 и сбежать в любой момент. Разве это не ужасно? Очевидно, что то, как поступить с этой «общественной собственностью», контролируемой контрактами Defi, является огромным сюрпризом. Это, собственно, и проблема распределения государственной власти. Ранее воры заявили в интервьюСоздание новых вещей в высокопроизводительных публичных цепочках сложно, смарт-контракты включают в себя распределение властиЭто было упомянуто в статье.

Во-вторых, если контракту не дать мигрировать, он понесет огромные убытки; Если контракту будет позволено перенести свое состояние на уровень 1, произойдет двойной вывод средств, который трудно решить в Plasma fraud proof:Например, мы предполагаем, что 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-го блока. Но если после блока No70 все Txn, которые взаимодействовали с контрактом миксера, не меняли статус контракта, за исключением транзакции, в которой Боб забрал 50 ETH; Если вы хотите показать доказательства, укажите, что контракт микшера находится в Если после блока No70 произойдет изменение, все упомянутые выше Txn должны быть запущены в цепочке Ethereum, и, наконец, контракт Plasma может быть подтвержден. Статус контракта на микшер действительно изменился (причина, по которой он такой сложный, заключается в том, что он определяется структурой самой плазмы). Если количество Txn в этом пакете очень велико, доказательство мошенничества вообще не может быть опубликовано на Layer1. (Это превысит лимит газа одного блока Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically, в приведенном выше сценарии двойного расходования кажется, что отправляется только снимок текущего состояния микшера (на самом деле доказательство Меркла, соответствующее StateRoot), но на самом деле, поскольку Plasma не публикует данные о транзакциях в цепочке, контракт не может определить, является ли отправленный снимок состояния действительным. Это связано с тем, что секвенсор сам может инициировать удержание данных, отправлять недопустимые снимки состояния и злонамеренно инкриминировать любого изъятого. Например, когда вы объявляете, что у вас есть 50 ETH на вашем счете, и инициируете вывод средств, секвенсор может в частном порядке очистить вашу учетную запись до 0, затем инициировать удержание данных, отправить недействительный StateRoot в цепочку и отправить соответствующий снимок состояния, ложно обвинив вас в том, что у вас закончились деньги на вашем счете. В настоящее время мы не можем доказать, что StateRoot и снимок состояния, отправленные секвенсором, являются недействительными, так как он инициировал удержание данных, и вы не можете получить достаточное количество данных, необходимых для защиты от мошенничества. Чтобы предотвратить это, когда узел Plasma представляет снимок состояния, чтобы доказать, что кто-то потратил дважды, он также воспроизводит записи транзакций в течение этого периода. Это может помешать секвенсору использовать удержание данных, чтобы предотвратить вывод денег другими пользователями. В Rollup, если вы столкнетесь с вышеупомянутым двойным выводом, теоретически нет необходимости воспроизводить исторические транзакции, потому что Rollup не имеет проблем с удержанием данных и будет «заставлять» секвенсор публиковать данные DA в цепочке. Если секвенсор свертки отправляет недопустимый моментальный снимок состояния StateRoot-state, он либо не пройдет проверку контракта (ZK Rollup), либо будет оспорен в ближайшее время (OP Rollup). На самом деле, в дополнение к упомянутому выше примеру с миксером монет, такие сценарии, как контракты с множественной подписью, также могут привести к двойному выводу средств в сети Plasma. Защита от мошенничества очень неэффективна в этом сценарии. Эта ситуация анализируется в ETH Research. Таким образом, поскольку решение Plasma не способствует смарт-контрактам и в основном не поддерживает миграцию статуса контракта на уровень 1, основная часть Plasma должна использовать UTXO или аналогичные механизмы. Поскольку UTXO не имеет проблемы конфликтов владения активами и может очень хорошо поддерживать защиту от мошенничества (он намного меньше по размеру), цена заключается в том, что он имеет один сценарий применения и может в основном поддерживать только переводы или биржи книги ордеров. Кроме того, поскольку само доказательство мошенничества сильно зависит от данных DA, если уровень DA ненадежен, будет трудно внедрить эффективную систему защиты от мошенничества. Тем не менее, подход Plasma к проблеме DA слишком груб и не может решить проблему атак с удержанием данных. С появлением Rollup Plasma постепенно сошла со сцены истории.

Disclaimer：

1. Эта статья взята из [Смарт-контрактМы на WeChat: Geek Web3]. Все авторские права принадлежат оригинальному автору [Фауст]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь со Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Перевод статьи на другие языки выполняется командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.