Retención de datos y prueba de fraude: por qué Plasma no admite contratos inteligentes

Autor: Faust, geek web3

En cuanto a por qué Plasma ha estado enterrado durante mucho tiempo y por qué Vitalik apoyará firmemente Rollup, las pistas apuntan principalmente a dos puntos: la implementación de DA fuera de la cadena en la cadena Ethereum no es confiable, y la retención de datos es fácil de ocurrir, y una vez que se produce la retención de datos, la prueba de fraude es difícil de desarrollar; **Estos dos puntos hacen que Plasma sea básicamente solo UTXO o modelos aproximados.

Para comprender estos dos puntos centrales, comencemos con DA y retención de datos. DA significa Data Avalibility, que se traduce literalmente como disponibilidad de datos, y ahora es mal utilizado por muchas personas, tanto que se confunde seriamente con “los datos históricos se pueden verificar”. Pero en realidad, los “datos históricos” y la “prueba de almacenamiento” son problemas de larga data que han sido resueltos por empresas como Filecoin y Arweave. Según la Fundación Ethereum y Celestia, el problema de DA se trata puramente de escenarios de retención de datos. **

Árbol de Merkle & Raíz de Merkle y Prueba de Merkle

Para ilustrar lo que significan los ataques de retención de datos y los problemas de DA, primero debemos hablar brevemente sobre Merkle Root y Merkle Tree. ** En Ethereum, o en la mayoría de las cadenas públicas, se utiliza una estructura de datos en forma de árbol llamada Merkle Tree para actuar como un resumen/directorio del estado de toda la cuenta, o para registrar las transacciones empaquetadas dentro de cada bloque.

**El nodo hoja en la parte inferior del árbol de Merkle se compone de hashes de datos sin procesar, como transacciones o estado de la cuenta, ** Estos hashes se suman en pares e iteraciones, y finalmente se puede calcular una raíz de Merkle.

(El registro en la parte inferior del diagrama es el conjunto de datos original correspondiente al nodo hoja)

La raíz de Merkle tiene una propiedad: si cambia un nodo hoja en la parte inferior del árbol de Merkle, la raíz de Merkle calculada también cambiará. Por lo tanto, los árboles de Merkle correspondientes a diferentes conjuntos de datos originales tendrán diferentes raíces de Merkle, al igual que diferentes personas tienen diferentes huellas dactilares. La tecnología de verificación de pruebas, conocida como Merkle Proof, aprovecha esta propiedad del Merkle Tree.

Por ejemplo, si Li Gang solo conoce el valor de la raíz de Merkle en la figura, no sabe qué datos contiene el árbol de Merkle completo. Necesitamos demostrarle a Li Gang que el Registro 3 está realmente relacionado con la raíz de la imagen, o que el hash del Registro 3 existe en el árbol de Merkle correspondiente a la raíz.

Solo necesitamos enviar Record3 y los 3 bloques de resumen marcados como grises a Li Gang, en lugar de confirmar todo el árbol de Merkle o todos sus nodos hoja, que es la simplicidad de Merkle Proof. Cuando el registro subyacente del árbol de Merkle tiene un gran número de hojas, como 2 elevado a 2 bloques de datos (aproximadamente 1 millón), la prueba de Merkle solo necesita contener al menos 21 bloques de datos.

(El bloque de datos 30 y H2 de la figura puede constituir una prueba de Merkle, lo que demuestra que el bloque de datos 30 existe en el árbol de Merkle correspondiente a H0)**

En Bitcoin, Ethereum o puentes entre cadenas, se suele utilizar esta “simplicidad” de Merkle Proof. El nodo ligero que conocemos es en realidad el Li Gang mencionado anteriormente, que solo recibe el encabezado del bloque del nodo completo, no del bloque completo. Es importante recalcar aquí que Ethereum utiliza un árbol de Merkle llamado State Trie, que actúa como un resumen de toda la cuenta. La raíz de Merkle del Trie estatal, denominada StateRoot, cambia cada vez que cambia el estado de una de las cuentas asociadas con el Trie estatal.

En el encabezado de bloque de Ethereum, se registrará StateRoot y también se registrará la raíz de Merkle (denominada raíz Txn) del árbol de transacciones. Si el bloque 100 contiene 300 transacciones, entonces las hojas del árbol comercial representan estos 300 Txn.

Otra diferencia es que la cantidad total de datos en State Trie es particularmente grande, y su hoja subyacente corresponde a todas las direcciones de la cadena Ethereum (de hecho, hay muchos hashes de estado obsoletos), por lo que el conjunto de datos original correspondiente a State Trie no se publicará en el bloque, solo se registrará StateRoot en el encabezado del bloque. El conjunto de datos original del árbol de transacciones son los datos Txn de cada bloque, y la raíz Txn del árbol se registrará en el encabezado del bloque.

Dado que el nodo ligero solo recibe el encabezado del bloque, solo conoce StateRoot y TxnRoot, y no puede deducir el árbol de Merkle completo basado en la raíz (esto está determinado por la naturaleza del árbol de Merkle y la función hash), el nodo de luz no puede conocer los datos de transacción contenidos en el bloque, ni sabe qué cambios se han producido en la cuenta correspondiente al Trie de estado. **

Si Wang Qiang quiere demostrarle a un nodo ligero (Li Gang mencionado anteriormente) que el bloque 100 contiene una determinada transacción, y se sabe que el nodo ligero conoce el encabezado del bloque 100 y conoce TxnRoot, entonces el problema anterior se traduce en: probar que este Txn existe en el árbol de Merkle correspondiente a TxnRoot. En este momento, Wang Qiang solo necesita enviar la prueba de Merkle correspondiente.

En muchos puentes de cadena cruzada basados en soluciones de cliente ligero, a menudo se utilizan la ligereza y la simplicidad de los nodos ligeros y la prueba de Merkle mencionada anteriormente. Por ejemplo, los puentes ZK como Map Protocol establecerán un contrato en la cadena ETH para recibir encabezados de bloque de otras cadenas (como Polygon). Cuando Relayer envía el encabezado del bloque número 100 de Polygon al contrato en la cadena ETH, el contrato verificará la validez del encabezado (por ejemplo, si tiene suficientes firmas de 2/3 nodos POS en la red Polygon).

Si el encabezado es válido y un usuario declara que ha iniciado un Txn de cadena cruzada de Polygon a ETH, el Txn se empaqueta en el bloque número 100 de Polygon. Solo necesita demostrar a través de Merkle Proof que el Txn de cadena cruzada que inició puede corresponder a la raíz Txn del encabezado del bloque 100 (en otras palabras, prueba que el Txn de cadena cruzada que inició tiene un registro en el bloque 100 de Polygon). Sin embargo, el puente ZK utilizará pruebas de conocimiento cero para comprimir la cantidad de cómputo necesario para verificar la prueba de Merkle, lo que reducirá aún más el costo de verificación de los contratos de puente entre cadenas.

Problemas de DA y ataques de retención de datos

Después de hablar sobre Merkle Tree y Merkle Root y Merkle Proof, volvamos al problema del ataque de DA y retención de datos mencionado al principio del artículo, que se exploró antes de 2017, y el artículo original de Celestia arqueó el origen del problema de DA. En un documento de 2017~18, el propio Vitalik habló sobre cómo los bloqueadores pueden ocultar deliberadamente ciertos fragmentos de datos del bloque y publicar bloques incompletos, de modo que los nodos completos no puedan confirmar la corrección de las transiciones de ejecución/estado de la transacción.

En este punto, el productor del bloque puede robar los activos del usuario, como transferir todas las monedas de la cuenta A a otra dirección, y el nodo completo no puede determinar si el propio A lo ha hecho, porque no conoce los datos completos de la transacción contenidos en el último bloque.

En las cadenas públicas de capa 1 como Bitcoin o Ethereum, los nodos completos honestos rechazarán directamente los bloques no válidos anteriores. Pero los nodos ligeros son diferentes, solo reciben el encabezado del bloque de la red, solo conocen el StateRoot y el TxnRoot, y no saben si el bloque original correspondiente al encabezado y las dos raíces es válido.

En el libro blanco de Bitcoin, en realidad hay un agujero cerebral para esta situación, Satoshi Nakamoto una vez creyó que la mayoría de los usuarios tenderán a ejecutar nodos ligeros con requisitos de configuración más bajos, y los nodos ligeros no pueden juzgar si el bloque correspondiente al encabezado del bloque es válido, y si un bloque no es válido, el nodo completo honesto enviará una alarma al nodo ligero.

Pero Satoshi Nakamoto no hizo un análisis más detallado de esta solución, y más tarde Vitalik y el fundador de Celestia, Mustafa, se basaron en esta idea, combinada con el trabajo de otros predecesores, para introducir el muestreo de datos DA para garantizar que los nodos completos honestos puedan restaurar los datos completos de cada bloque y generar una alarma cuando sea necesario.

Nota: DA Data Sampling (DAS) y Celestia no son el foco de este artículo, los lectores interesados pueden leer el artículo anterior de Geek Web3: “Conceptos erróneos sobre la disponibilidad de datos: DA = Publicación de datos ≠ recuperación de datos históricos”

A prueba de fraude de Plasma

En pocas palabras, Plasma es una solución de escalado que solo publica encabezados de bloque de capa 2 en capa 1, y los datos de DA fuera del encabezado de bloque (conjunto completo de datos de transacción/cambio de estado por cuenta) solo se publican fuera de la cadena. En otras palabras, Plasma es como un puente de cadena cruzada basado en clientes ligeros, implementando un cliente ligero de capa 2 con un contrato en la cadena ETH, y cuando un usuario declara que quiere cruzar activos de L2 a L1, debe presentar una prueba de Merkle para demostrar que realmente posee los activos.

** La lógica de verificación para los activos que abarcan de L2 a L1 es similar al puente ZK mencionado anteriormente, excepto que el modelo de puente de plasma se basa en pruebas de fraude en lugar de pruebas ZK, que está más cerca del llamado “puente optimista”. ** Las solicitudes de retiro de L2 a L1 en la red Plasma no se liberan de inmediato, sino que tienen un “período de desafío”, ya que para el propósito del período de desafío, lo explicaremos a continuación.

Plasma no tiene requisitos estrictos para la liberación de datos/DA, el secuenciador/operador simplemente transmite cada bloque L2 fuera de la cadena, y los nodos que están dispuestos a obtener el bloque L2 lo hacen por su cuenta. Después de eso, el secuenciador publicará el encabezado del bloque L2 en la Capa 1. Por ejemplo, el secuenciador transmite el bloque 100 fuera de la cadena y luego publica el encabezado del bloque en la cadena. Si el bloque 100 contiene transacciones no válidas, cualquier nodo de plasma puede enviar una prueba de Merkle al contrato en ETH antes de que finalice el “período de desafío” para demostrar que el encabezado del bloque 100 puede asociarse con una transacción no válida, que es un escenario cubierto por pruebas de fraude.

Los casos de uso a prueba de fraude de Plasma también incluyen los siguientes:

1. Supongamos que el progreso de la red Plasma alcanza el bloque 200, y el usuario A inicia una declaración de retiro, diciendo que tiene 10 ETH en el bloque 100. Pero, de hecho, el usuario A gastó el ETH en la cuenta después del bloque 100.

Entonces, el comportamiento de A es en realidad gastar 10 ETH, declarar que tuvo 10 ETH en el pasado e intentar retirar el ETH. Este es el clásico “doble retiro”, doble gasto. En este momento, cualquiera puede presentar una prueba de Merkle para demostrar el último estado de activo del usuario A y no cumple con su declaración de retiro, es decir, para demostrar que A no tenía una declaración de retiro después del bloque 100 (diferentes esquemas de Plasma tienen métodos de prueba inconsistentes para esta situación, y el modelo de dirección de cuenta es mucho más problemático que la prueba de doble gasto de UTXO).

2. Si se trata de un esquema de Plasma basado en el modelo UTXO (que era principalmente el caso en el pasado), no hay StateRoot en el encabezado del bloque, solo TxnRoot (UTXO no admite el modelo de dirección de cuenta al estilo Ethereum, ni tiene un diseño de estado global como State Trie). En otras palabras, una cadena que adopta el modelo UTXO solo tiene registros de transacciones, no registros estatales.

En este caso, el propio secuenciador puede lanzar un ataque de doble gasto, como gastar un UTXO que ya se ha gastado o emitir UTXO adicionales a un usuario de la nada. Cualquier usuario puede enviar una prueba de Merkle para demostrar que el historial de uso de la UTXO ha aparecido (se ha gastado) en bloques anteriores, o para demostrar que el origen histórico de una UTXO es cuestionable. **

3. En el caso de los esquemas de Plasma compatibles con EVM/habilitados para State-Trie, es posible que el secuenciador envíe un StateRoot no válido, por ejemplo, después de ejecutar la transacción contenida en el bloque 100, el StateRoot debe convertirse a ST+, pero el secuenciador envía ST- a la Capa 1.

En este caso, la prueba de fraude es más compleja y requiere que la transacción en el bloque 100 se reproduzca en la cadena Ethereum, que consume mucho gas con la cantidad de parámetros de cálculo y entrada requeridos. Es difícil para los primeros equipos de adopción de Plasma lograr pruebas de fraude tan complejas, por lo que la mayoría de ellos utilizan el modelo UTXO, después de todo, las pruebas de fraude basadas en UTXO son muy simples y fáciles de implementar (Fuel, el primer esquema Rollup para lanzar pruebas de fraude, se basa en UTXO)

Juego de retención y salida de datos****

Por supuesto, los escenarios mencionados anteriormente en los que las pruebas de fraude pueden surtir efecto solo se establecen cuando la publicación de datos/DA es válida. Si el secuenciador retiene datos y no publica el bloque completo fuera de la cadena, el nodo de Plasma no podrá confirmar si el encabezado del bloque en la Capa 1 es válido y, por supuesto, no podrá publicar la prueba de fraude sin problemas.

En este momento, el secuenciador puede robar los activos del usuario, como transferir todas las monedas de la cuenta A a la cuenta B, luego transferir dinero de la cuenta B a la C y, finalmente, iniciar un retiro a nombre de C. Las cuentas B y C son propiedad del secuenciador, y la transferencia de B->C es inofensiva incluso si se publica al público.** Pero el secuenciador puede retener los datos de la transferencia no válida de A->B, y las personas no pueden probar que hay un problema con la fuente de los activos de B y C** (para probar que la fuente de los activos de B es problemática, es necesario señalar que la firma digital de “un cierto Txn transferido a B” es incorrecta).

La solución Plasma basada en UTXO está dirigida por el hecho de que cualquier persona que inicie un retiro debe enviar el historial completo del activo, aunque hay más mejoras más adelante. Sin embargo, si se trata de una solución de plasma compatible con EVM, será débil en esta área. Porque si el Txn relacionado con el contrato está involucrado, habrá un costo enorme en la verificación del proceso de transición de estado en la cadena, por lo que es difícil implementar un esquema de verificación para la validez de los retiros mediante el soporte del modelo de dirección de cuenta y el contrato inteligente Plasma.

Además, aparte del tema anterior, ya sea que se trate de Plasma basado en UTXO o en un modelo basado en direcciones de cuenta, la retención de datos puede causar pánico porque no sabe qué transacciones está realizando el secuenciador. ** Los nodos de plasma encontrarán algo mal, pero no podrán publicar pruebas de fraude porque el secuenciador de plasma no enviará los datos necesarios para las pruebas de fraude.

En este momento, las personas solo pueden ver el encabezado del bloque correspondiente, pero no saben qué hay en el bloque y no saben en qué se han convertido los activos de su cuenta, por lo que iniciarán colectivamente una declaración de retiro e intentarán retirar con la prueba de Merkle correspondiente al bloque histórico, desencadenando un escenario extremo llamado “Juego de salida”, que conducirá a una “estampida”, que hará que la Capa 1 esté seriamente congestionada y aún causará daños en los activos de algunas personas (Las personas que no reciben notificaciones honestas de nodos o no deslizan Twitter no sabrán que el secuenciador está robando monedas).

Por lo tanto, Plasma es una solución de escalado de capa 2 poco fiable, y una vez que se produce un ataque de retención de datos, se desencadenará un “juego de salida”, que es fácil para los usuarios sufrir pérdidas, lo que es una de las principales razones de su abandono. **

Razones por las que el plasma es difícil de soportar contratos inteligentes****

Después de hablar sobre Exit Game y los problemas de retención de datos, veamos por qué Plasma es difícil de admitir contratos inteligentes, principalmente por dos razones:

En primer lugar, si se trata de un activo de un contrato Defi, ¿quién debería retirarlo a la Capa 1? Debido a que esto es esencialmente migrar el estado del contrato de la Capa 2 a la Capa 1, supongamos que alguien carga 100 ETH al grupo de LP del DEX, y luego el secuenciador de Plasma hace el mal, y la gente quiere retirarse urgentemente, en este momento, los 100 ETH del usuario todavía están controlados por el contrato DEX, ¿quién debería mencionar estos activos a la Capa 1 en este momento?

La mejor manera de hacer esto parece ser dejar que el usuario canjee los activos del DEX primero, y luego el usuario retirará el dinero a L1 por sí mismo, pero el problema es que el secuenciador de Plasma ha hecho algo malo y puede rechazar la solicitud del usuario en cualquier momento.

Entonces, ¿qué pasa si configuramos un propietario para el contrato DEX por adelantado, lo que le permite colocar los activos del contrato en L1 en caso de una emergencia? Obviamente, esto le dará al propietario del contrato la propiedad de los activos públicos, y puede poner estos activos en L1 en cualquier momento y huir, ¿no sería terrible?

Obviamente, qué hacer con esta “propiedad pública” dominada por los contratos Defi es un gran trueno. ** En realidad, esto implica el problema de la distribución del poder público, del que Xiangma ha hablado anteriormente en una entrevista con “Es difícil para las cadenas públicas de alto rendimiento hacer cosas nuevas, y los contratos inteligentes implican la distribución del poder”.

En segundo lugar, si no se permite que el contrato migre su estado, sufrirá una gran pérdida, y si se permite que el contrato migre su estado a la Capa 1, habrá retiros dobles que son difíciles de resolver con la prueba de fraude de Plasma:

Por ejemplo, supongamos que Plasma adopta el modelo de dirección de cuenta de Ethereum, admite contratos inteligentes, tiene un mezclador de monedas, actualmente deposita 100 ETH y el propietario del mezclador de monedas está controlado por Bob;

Digamos que Bob retira 50 ETH del mezclador en el bloque 100. Después de eso, Bob inició una declaración de retiro y cruzó los 50 ETH a la Capa 1;

Después de eso, Bob usa una instantánea del estado del contrato pasado (por ejemplo, el bloque 70) para migrar el estado pasado del mezclador a la Capa 1, que también cruzará los 100 ETH que el mezclador “alguna vez tuvo” a la Capa 1.

Obviamente, se trata de un típico “doble drawdown”, que es un doble gasto. ** Bob mencionó 150 ETH a la Capa 1, pero los usuarios de la red de la Capa 2 solo pagaron 100 ETH al mezclador/Bob, y 50 ETH se retiraron de la nada. Esto puede agotar fácilmente las reservas de Plasma**. Teóricamente, se podría iniciar una prueba de fraude para demostrar que el estado del contrato de mezclador ha cambiado después del bloque 70.

Pero si quieres mostrar pruebas de que el contrato de Mixer ha cambiado después del Bloque 70, tienes que ejecutar todo el Txn mencionado anteriormente en la cadena de Ethereum para finalmente dejar que el contrato de Plasma determine que el estado del contrato de Mixer ha cambiado (la razón por la que es tan complejo está determinada por la propia estructura de Plasma). Si la cantidad de Txn es tan grande, la prueba de fraude no se publicará en la Capa 1 en absoluto (excederá el límite de gas para un solo bloque de Ethereum).

Teóricamente, en el escenario de doble gasto anterior, parece que solo necesita enviar una instantánea del estado actual del mezclador (que en realidad es la prueba de Merkle correspondiente a StateRoot), pero de hecho, dado que Plasma no publica datos de transacciones en la cadena, el contrato no puede determinar si la instantánea del estado que envía es válida. ** Esto se debe a que el propio secuenciador puede iniciar la retención de datos, enviar instantáneas de estado no válidas y señalar maliciosamente cualquier retirada. **

Por ejemplo, cuando declaras que tienes 50 ETH en tu cuenta e inicias un retiro, el secuenciador puede borrar tu cuenta de forma privada a 0 y, a continuación, iniciar la retención de datos, enviar un StateRoot no válido a la cadena y enviar una instantánea de estado correspondiente para acusarte falsamente de quedarte sin dinero en tu cuenta. En este momento, no se puede demostrar que StateRoot y State Snapshot enviados por el secuenciador no son válidos, ya que él inició la retención de datos y no se obtienen los datos suficientes necesarios para demostrar el fraude. **

Para evitar esto, el nodo Plasma también reproduce el historial de transacciones durante este período cuando presenta una instantánea del estado para demostrar que alguien tiene un doble gasto, lo que evita que el secuenciador retenga datos para evitar que otros los retiren. En Rollup, si se encuentra con el doble retiro mencionado anteriormente, no necesita reproducir la transacción histórica en teoría, porque Rollup no tiene el problema de la retención de datos y “obligará” al secuenciador a publicar datos de DA en la cadena. ** Los secuenciadores de paquetes acumulativos que envíen una instantánea de estado StateRoot no válida no podrán realizar un error en la validación del contrato (ZK Rollup) o pronto serán impugnados (OP Rollup).

De hecho, además del ejemplo del mezclador de monedas mencionado anteriormente, escenarios como los contratos multifirma también pueden dar lugar a retiros dobles en la red Plasma. Las pruebas de fraude son ineficientes en el manejo de tales escenarios. **Esta situación se analiza en ETH Research.

En resumen, debido a que el esquema de Plasma no es propicio para los contratos inteligentes y básicamente no admite la migración del estado del contrato a la Capa 1, la corriente principal de Plasma tiene que elegir UTXO o mecanismos similares, porque UTXO no tiene el problema del conflicto de propiedad de activos y puede admitir a prueba de fraude (mucho más pequeño en tamaño), pero a costa de un solo escenario de aplicación, básicamente solo puede admitir intercambios de libros de pedidos o transferencias.

Además, debido a que la prueba de fraude en sí misma tiene una fuerte dependencia de los datos de DA, será difícil lograr un sistema eficiente de prueba de fraude si la capa de DA no es confiable. Sin embargo, el manejo de los problemas de DA por parte de Plasma es demasiado rudimentario para resolver el problema de los ataques de retención de datos, y con el auge de Rollup, Plasma se ha desvanecido lentamente de la historia. **