En cuanto a por qué Plasma ha estado enterrado durante mucho tiempo, y por qué Vitalik apoyará firmemente a Rollup, las pistas apuntan principalmente a dos puntos: implementar DA bajo la cadena Ethereum no es fiable y es fácil que ocurra la retención de datos. Una vez que ocurre la retención de datos, la prueba de fraude es difícil de llevar a cabo; El diseño del mecanismo de Plasma en sí mismo es extremadamente hostil para los contratos inteligentes, y es especialmente difícil admitir la migración del estado del contrato a la Capa 1. Estos dos puntos hacen que Plasma básicamente solo use UTXO u otros modelos similares.

Para entender los dos puntos principales anteriores, comencemos con los problemas de DA y retención de datos. El nombre completo de DA es Disponibilidad de Datos, que se traduce literalmente como disponibilidad de datos. Ahora es mal utilizado por muchas personas. Tanto es así que se confunde seriamente con "los datos históricos se pueden verificar". Pero de hecho, "los datos históricos se pueden verificar" y "prueba de almacenamiento" son problemas que Filecoin y Arweave ya han resuelto. Según la Fundación Ethereum y Celestia, el problema de DA explora puramente escenarios de retención de datos.

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

Para explicar qué significan realmente los ataques de retención de datos y los problemas de DA, primero necesitamos hablar brevemente sobre la Raíz de Merkle y el Árbol de Merkle. En Ethereum o la mayoría de las cadenas públicas, se utiliza una estructura de datos en forma de árbol llamada Árbol de Merkle para servir como un resumen/directorio del estado de todas las cuentas, o para registrar las transacciones empaquetadas en cada bloque.

El nodo hoja en la parte inferior del árbol de Merkle está compuesto por hashes de datos originales como transacciones o estado de cuenta. Estos hashes se suman en pares e iteran repetidamente, y finalmente se puede calcular una Raíz de Merkle.

(El registro en la parte inferior de la figura es el conjunto de datos original correspondiente al nodo hoja) La Raíz de Merkle tiene una propiedad: si un nodo hoja en la parte inferior del Árbol de Merkle cambia, 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 Raíces de Merkle diferentes, al igual que diferentes personas tienen diferentes huellas dactilares. La tecnología de verificación de prueba llamada Prueba de Merkle aprovecha esta propiedad del Árbol de Merkle. Tomando la imagen anterior como ejemplo, si Li Gang solo conoce el valor de la Raíz de Merkle en la imagen, no sabe qué datos contiene el Árbol de Merkle completo. Queremos demostrar a Li Gang que el Registro 3 está realmente relacionado con la Raíz en la imagen, o en otras palabras, demostrar que el hash del Registro 3 existe en el Árbol de Merkle correspondiente a la Raíz. Solo necesitamos enviar a Li Gang el Registro 3 y los tres bloques de datos digest marcados en gris, sin tener que enviar todo el Árbol de Merkle o todos sus nodos hoja. Así de simple es la Prueba de Merkle. Cuando los registros subyacentes del Árbol de Merkle contienen muchas hojas, por ejemplo, contiene 2 a la 20ª potencia de 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 en la figura pueden constituir una Prueba de Merkle, demostrando que el bloque de datos 30 existe en el Árbol de Merkle correspondiente a H0) Esta "simplicidad" de la Prueba de Merkle se usa a menudo en Bitcoin, Ethereum o puentes entre cadenas. El nodo ligero que conocemos es en realidad el mencionado anteriormente Li Gang. Él solo recibe el encabezado del bloque del nodo completo, no el bloque completo. Es necesario enfatizar aquí que Ethereum utiliza un árbol de Merkle llamado State Trie para servir como resumen de todas las cuentas. Si cambia el estado de una cuenta asociada con State Trie, la Raíz de Merkle de State Trie, llamada StateRoot, cambiará. En el encabezado del bloque de Ethereum, se registrará el StateRoot, y también se registrará la Raíz de Merkle del árbol de transacciones (denominada Txn Root). Una diferencia entre un árbol de transacciones y un árbol de estados es que los datos representados por las hojas subyacentes son diferentes. Si el bloque n.º 100 contiene 300 transacciones, las hojas del árbol de transacciones representan estas 300 Txn. Otra diferencia es que el volumen total de datos de State Trie es extremadamente grande. Sus hojas inferiores corresponden a todas las direcciones en la cadena de 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á el StateRoot en el encabezado del bloque. El conjunto de datos original del árbol de transacciones es los datos Txn en cada bloque, y el TxnRoot de este árbol se registrará en el encabezado del bloque.

Dado que el nodo ligero solo recibe el encabezado de bloque y solo conoce StateRoot y TxnRoot, no puede deducir el árbol de Merkle completo basado en la Raíz (esto está determinado por las propiedades del árbol de Merkle y la función hash), por lo que los nodos ligeros no pueden conocer los datos de transacción contenidos en el bloque, ni saben qué cambios han ocurrido en la cuenta correspondiente al State Trie. Si Wang Qiang quiere demostrar a un nodo ligero (Li Gang mencionado anteriormente) que el bloque n.° 100 contiene una determinada transacción, y se sabe que el nodo ligero conoce el encabezado de bloque del bloque n.° 100 y conoce TxnRoot, entonces el problema anterior se transforma en: Demostrar que esta 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 interconectados basados en soluciones de clientes ligeros, la ligereza y simplicidad de los nodos ligeros y la Prueba de Merkle mencionada anteriormente suelen ser utilizadas. Por ejemplo, los puentes ZK como Map Protocol establecerán un contrato en la cadena ETH para recibir específicamente encabezados de bloques de otras cadenas (como Polygon). Cuando el Relayer envía el encabezado del bloque 100 de Polygon al contrato en la cadena ETH, el contrato verificará la validez del encabezado (por ejemplo, si ha recopilado las firmas de 2/3 de los nodos POS en la red de Polygon). Si el encabezado es válido y un usuario declara que inició una transacción interconectada desde Polygon a ETH, la transacción se empaquetará en el bloque 100 de Polygon. Solo necesita usar la Prueba de Merkle para demostrar que la transacción interconectada iniciada por él puede corresponder al TxnRoot en el encabezado de bloque n. ° 100 (en otras palabras, es para demostrar que la transacción interconectada iniciada por usted está registrada en el bloque 100 de Polygon). Sin embargo, ZK Bridge utilizará una prueba de conocimiento cero para comprimir la cantidad de cálculo requerida para verificar la Prueba de Merkle, reduciendo aún más el costo de verificación de los contratos de puentes interconectados.

Problemas de ataque DA y retención de datos

Después de hablar sobre el Árbol de Merkle, la Raíz de Merkle y la Prueba de Merkle, volvamos al tema de DA y los ataques de retención de datos mencionados al principio del artículo. Este problema se ha discutido tan temprano como en 2017. El documento original de Celestia tiene la fuente del problema de DA. Realiza arqueología. Vitalik mismo mencionó en un documento de 2017 a 2018 que el productor de bloques puede ocultar deliberadamente ciertos fragmentos de datos del bloque y liberar bloques incompletos al mundo exterior. Como resultado, el nodo completo no puede confirmar la corrección de la ejecución de transacciones / transición de estado.

En este momento, el productor de bloques puede robar los activos del usuario, como transferir todas las monedas de la cuenta de A a otras direcciones, pero el nodo completo no puede juzgar si A mismo ha hecho esto porque no conocen la transacción completa incluida en el último bloque de datos.

En las cadenas públicas de la Capa 1, como Bitcoin o Ethereum, los nodos completos honestos rechazarán directamente los bloques inválidos anteriores. Pero los nodos ligeros son diferentes. Solo reciben encabezados de bloque de la red. Solo conocemos el EstadoRaíz y TxnRaíz, pero no sabemos si el Encabezado y los bloques originales correspondientes a las dos Raíces son válidos.

En el libro blanco de Bitcoin, en realidad hay algo de reflexión sobre esta situación. Satoshi Nakamoto creía una vez que la mayoría de los usuarios tenderían 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. Si un bloque no es válido, los nodos completos honestos enviarán una alerta a los nodos ligeros.

Sin embargo, Satoshi Nakamoto no realizó un análisis más detallado de esta solución. Más tarde, Vitalik y el fundador de Celestia, Mustafa, combinaron esta idea con los resultados de otros predecesores e introdujeron el muestreo de datos DA para garantizar que los nodos completos honestos puedan restaurar cada área de datos completa y generar alertas cuando sea necesario.

Nota: El Muestreo de Datos de DA (DAS) y Celestia no son el foco de este artículo. Los lectores interesados pueden leer artículos anteriores de “Geek Web3”:"Malentendido de Disponibilidad de Datos: DA = Liberación de Datos ≠ Recuperación de Datos Históricos"

Prueba de fraude de Plasma

En pocas palabras, Plasma es una solución de expansión que solo publica el encabezado del bloque de Layer2 a Layer1, y los datos DA fuera del encabezado del bloque (conjunto de datos de transacciones completas/cambios de estado de cada cuenta) solo se publican fuera de la cadena. En otras palabras, Plasma es como un puente entre cadenas basado en clientes ligeros. Utiliza contratos para implementar clientes ligeros de Layer 2 en la cadena ETH. Cuando los usuarios declaran que desean transferir activos de L2 a L1, deben enviar una prueba de Merkle para demostrar que son propietarios de estos activos. La lógica de verificación de la transferencia de activos 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, no en pruebas ZK, y se acerca al llamado “puente optimista”. Las solicitudes de retiro de L2 a L1 en la red de Plasma no se publicarán de inmediato, sino que habrá un “período de desafío”. En cuanto al 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 solo transmite cada bloque L2 fuera de la cadena, y los nodos que deseen obtener bloques L2 pueden hacerlo por sí mismos. Posteriormente, el clasificador publicará el encabezado del bloque L2 en la Capa 1. Por ejemplo, el secuenciador primero transmite el bloque N.° 100 fuera de la cadena, y luego publica el encabezado del bloque en la cadena. Si el bloque 100 contiene transacciones inválidas, cualquier nodo de Plasma puede enviar una Prueba de Merkle al contrato en ETH antes del final del “período de desafío”. Demostrar que el encabezado del bloque N.° 100 puede estar asociado con una transacción inválida, Este es un escenario cubierto por la prueba de fraude.

Los escenarios de aplicación de prueba de fraude de Plasma también incluyen lo siguiente:1. Supongamos que el progreso de la red de Plasma alcanza el bloque No. 200. En este momento, el usuario A inicia una declaración de retiro, diciendo que cuando estaba en el bloque No. 100, tenía 10 ETH. Pero de hecho, el usuario A gastó los ETH en su cuenta después del bloque 100. Por lo tanto, el comportamiento de A es en realidad: después de gastar 10 ETH, declara que tenía 10 ETH en el pasado e intenta retirar estos ETH. Esto es un típico “doble retiro” y doble gasto. en este momento, Cualquiera puede presentar Prueba de Merkle para demostrar que el estado de activos más reciente del usuario A no satisface su declaración de retiro, es decir, para demostrar que A no ha retirado el dinero declarado después del bloque 100. (Los esquemas de Plasma diferentes 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 una solución de Plasma basada en el modelo UTXO (esto fue principalmente el caso en el pasado), el encabezado de bloque no contiene StateRoot, solo TxnRoot (UTXO no admite el modelo de dirección de cuenta al estilo Ethereum, y no hay un estado global como State Trie) diseño). En otras palabras, una cadena que utiliza el modelo UTXO solo tiene registros de transacciones y no registros de estado. En este momento, el secuenciador mismo puede lanzar un ataque de doble gasto, como gastar un UTXO que ha sido gastado nuevamente, o emitir UTXO adicionales a un usuario de la nada. Cualquier usuario puede presentar una Prueba de Merkle para demostrar que el registro de uso del UTXO ha aparecido (fue gastado) en bloques anteriores, o para demostrar que hay un problema con la fuente histórica de un cierto UTXO.

1. Para las soluciones de Plasma compatibles con EVM/State Trie, el clasificador puede enviar un StateRoot inválido. Por ejemplo, después de ejecutar la transacción contenida en el bloque 100, el StateRoot debería convertirse en ST+, pero el clasificador va a Layer1 y envía ST-. La prueba de fraude en este caso es más complicada y requiere volver a ejecutar la transacción en el bloque No. 100 en la cadena de Ethereum. La cantidad de cálculo y los parámetros de entrada requeridos consumirán mucho gas. Los equipos que adoptaron tempranamente Plasma tuvieron dificultades para lograr pruebas de fraude tan complejas, por lo que la mayoría de ellos adoptaron el modelo UTXO. Después de todo, las pruebas de fraude basadas en UTXO son simples y fáciles de implementar. (Fuel, la primera solución de rollup que proporciona pruebas de fraude, se basa en UTXO)

Retención de datos y Juego de salida Por supuesto, los escenarios anteriores en los que la prueba de fraude puede ser efectiva solo se establecen cuando la DA/liberación de datos es efectiva. Si el secuenciador se dedica a retener datos y no publica bloques completos fuera de la cadena, el nodo de Plasma no podrá confirmar si el encabezado de bloque en la Capa 1 es válido, y por supuesto no podrá emitir pruebas de fraude con fluidez.

En este punto, el secuenciador puede robar los activos del usuario, por ejemplo, transferir de forma privada todas las monedas de la cuenta A a la cuenta B, luego transferir dinero de la cuenta B a la cuenta C y, finalmente, iniciar un retiro a nombre de C. Las cuentas B y C son propiedad del propio secuenciador. Incluso si la transferencia B->C se hace pública, no causará ningún daño; Pero el clasificador puede retener los datos de la transferencia no válida A->B, y las personas no pueden probar que hay un problema con la fuente de los activos de B y C. (Para demostrar que la fuente de los activos de B es sospechosa, es necesario señalar que la firma digital de "un determinado Txn transferido a B" es incorrecta). La solución de plasma basada en UTXO tiene medidas específicas. Por ejemplo, cuando alguien inicia un retiro, debe presentar todas las fuentes históricas de los activos. Por supuesto, habrá más medidas de mejora más adelante. Pero si se trata de una solución de plasma compatible con EVM, parecerá débil en esta área. Debido a que si Txn relacionado con el contrato está involucrado, verificar el proceso de transición de estado en la cadena incurrirá en enormes costos, por lo tanto, Plasma, que admite modelos de direcciones de cuentas y contratos inteligentes, no puede implementar fácilmente un esquema de verificación para la validez de los retiros. Además, aparte del tema anterior, ya sea que se trate de Plasma basado en UTXO o el modelo de dirección de cuenta, una vez que se produce la retención de datos, básicamente hará que las personas entren en pánico porque no sabe qué transacciones ha ejecutado el secuenciador. Los nodos de plasma descubrirán que algo anda mal, pero no podrán emitir pruebas de fraude porque el secuenciador de plasma no ha emitido 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 o qué ha pasado con los activos de su cuenta. Todos iniciarán colectivamente una declaración de retiro y usarán el encabezado de bloque correspondiente. Merkle Proof intenta retirar dinero, desencadenando un escenario extremo llamado "Juego de salida", esta situación conducirá a una "estampida", causando una grave congestión en la Capa 1, y aún causará daños en los activos de algunas personas. (Las personas que no hayan recibido notificaciones honestas de nodos o que no revisen Twitter no sabrán que el secuenciador está robando monedas).

Por lo tanto, Plasma es una solución de expansión de Capa 2 poco fiable. Una vez que ocurre un ataque de retención de datos, se activará el "Juego de Salida", lo que puede causar fácilmente pérdidas a los usuarios. Esta es una de las principales razones de su abandono. ¿Por qué Plasma tiene dificultades para admitir contratos inteligentes? Después de hablar sobre el Juego de Salida y los problemas de retención de datos, veamos por qué Plasma tiene dificultades para admitir contratos inteligentes. Hay dos razones principales: Primero, si es un activo de un contrato Defi, ¿quién debería retirarlo a la Capa 1? Porque esto es básicamente migrar el estado del contrato de la Capa 2 a la Capa 1. Supongamos que alguien deposita 100 ETH en el grupo de liquidez de DEX, y luego el secuenciador de Plasma hace algo malvado, y la gente quiere retirar dinero con urgencia. En este momento, los 100 ETH del usuario siguen controlados por el contrato DEX. ¿Quién debería poseer estos activos en este momento? ¿Mencionado en la Capa 1? La mejor manera parece ser permitir a los usuarios canjear activos de DEX primero, y luego permitir a los usuarios transferir el dinero a L1 ellos mismos. Pero el problema es que el clasificador de Plasma ha hecho algo malvado y puede rechazar las solicitudes de los usuarios en cualquier momento. Entonces, ¿qué pasa si configuramos el Propietario para el contrato DEX con antelación y le permitimos levantar los activos del contrato a L1 en caso de emergencia? Obviamente, esto le dará al propietario del contrato la propiedad de los activos públicos. Él puede llevar estos activos a L1 y huir en cualquier momento. ¿No es terrible? Obviamente, cómo lidiar con estos "bienes públicos" controlados por contratos Defi es una gran sorpresa. Esto realmente implica el problema de la distribución del poder público. Los ladrones habían dicho anteriormente en una entrevistaEs difícil crear cosas nuevas en cadenas públicas de alto rendimiento, los contratos inteligentes implican la distribución de poderEsto fue mencionado en el artículo.

En segundo lugar, si no se permite que el contrato migre, sufrirá enormes pérdidas; Si se permite que el contrato migre su estado a la Capa 1, habrá un doble retiro que es difícil de resolver en Plasma a prueba de fraude:Por ejemplo, suponemos que Plasma adopta el modelo de dirección de cuenta de Ethereum y admite contratos inteligentes., hay un mezclador, actualmente depositado con 100 ETH, y el propietario del mezclador está controlado por Bob; supongamos que Bob retira 50 ETH del mezclador en el bloque 100. Después, Bob inicia una declaración de retiro y transfiere los 50 ETH a Layer1; luego, Bob usa la instantánea del estado del contrato anterior (como el bloque 70) para migrar el estado pasado del mezclador a la Capa 1, lo que Los 100 ETH que el mezclador "solía poseer" también se transfirieron a la Capa 1; obviamente, este es un típico "doble retiro", es decir, 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 podría agotar fácilmente las reservas de plasma。 En teoría, se podría iniciar una prueba de fraude para demostrar que el estado del contrato de la mezcladora cambió después del bloque 70. Pero si después del bloque No. 70, todos los Txn que interactuaron con el contrato del mezclador no cambiaron el estado del contrato, excepto por la transacción en la que Bob se llevó 50 ETH; si desea mostrar pruebas, señale que el contrato del mezclador está en Si hay un cambio después del bloque No. 70, todos los Txn mencionados anteriormente deben ejecutarse en la cadena Ethereum y, finalmente, se puede confirmar el contrato de Plasma. De hecho, el estado del contrato del mezclador ha cambiado (la razón por la que es tan complicado es porque está determinado por la estructura del propio plasma). Si el número de Txn en este lote es extremadamente grande, la prueba de fraude no se puede publicar en la capa 1 en absoluto. (Excederá el límite de gas de un solo bloque de Ethereum).

https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598Theoretically, en el escenario de doble gasto anterior, parece que solo se envía la instantánea de estado actual del mezclador (en realidad, 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 de estado enviada 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 e incriminar maliciosamente a cualquier retirante. 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, luego iniciar la retención de datos, enviar un StateRoot no válido a la cadena y enviar la instantánea de estado correspondiente, acusándote falsamente de quedarte sin dinero en tu cuenta. En este momento, no podemos demostrar que StateRoot y la instantánea de estado enviadas por el secuenciador no sean válidas, ya que ha iniciado la retención de datos y no puede obtener suficientes datos necesarios para la prueba de fraudes. Para evitar esto, cuando un nodo de Plasma presenta una instantánea de estado para demostrar que alguien ha gastado dos veces, también reproducirá los registros de transacciones durante este período. Esto puede evitar que el secuenciador utilice la retención de datos para evitar que otros retiren dinero. En Rollup, si se encuentra con el doble retiro mencionado anteriormente, teóricamente no hay necesidad de reproducir transacciones históricas, porque Rollup no tiene problemas de retención de datos y "obligará" al secuenciador a publicar datos de DA en la cadena. Si el secuenciador acumulativo envía una instantánea de estado StateRoot no válida, se producirá un error en la verificación del contrato (ZK Rollup) o se impugnará pronto (OP Rollup). De hecho, además del ejemplo del mezclador de monedas mencionado anteriormente, escenarios como los contratos de firma múltiple también pueden conducir a retiros dobles en la red Plasma. La prueba de fraude es muy ineficiente en el manejo de este escenario. Esta situación se analiza en ETH Research. En resumen, dado que la solución Plasma no es propicia 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 usar UTXO o mecanismos similares. Debido a que UTXO no tiene el problema de los conflictos de propiedad de activos y puede soportar muy bien la prueba de fraude (es mucho más pequeño en tamaño), el precio es que tiene un único escenario de aplicación y básicamente solo puede admitir transferencias o intercambios de libros de órdenes. Además, debido a que la prueba de fraude en sí misma tiene una fuerte dependencia de los datos de DA, si la capa de DA no es confiable, será difícil implementar un sistema eficiente de prueba de fraude. Sin embargo, el manejo del problema de DA por parte de Plasma es demasiado crudo y no puede resolver el problema de los ataques de retención de datos. Con el auge de Rollup, Plasma desapareció lentamente del escenario de la historia.

Descargo de responsabilidad：

1. Este artículo ha sido reimpreso de [Cuenta oficial de WeChat: Geek Web3]. Todos los derechos de autor pertenecen al autor original [Faust]. If there are objections to this reprint, please contact theGate Learnequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen asesoramiento de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.