Recientemente,Un proyecto llamado Redstone se ha convertido en un tema candente.Esta instalación especial de Capa 2 para juegos en cadena lanzada por el equipo de Lattice se lanzó oficialmente el 15 de noviembre y ahora está en línea en la red de prueba. Curiosamente, el equipo de Lattice declaró: “Redstone es una cadena Alt-DA inspirada en Plasma”。

Justo el día antes del lanzamiento de Redstone, Vitalik acaba de publicar el artículo “Salir de los juegos para validiums de EVM: el regreso de Plasma”. El artículo revisó brevemente la solución técnica "Plasma" que ha desaparecido del ecosistema Ethereum y señaló que se puede introducir una prueba de validez (confundida con ZK Proof) para resolver el problema de Plasma. En este sentido, muchos amigos creen que Vitalik publicó este artículo para apoyar a Redstone. Algunas personas incluso dijeron en la comunidad geek Web3 que Vitalik podría haber invertido en Redstone. Junto con la acalorada “disputa sobre la definición de la capa 2 de Ethereum” en esta precuela, la gente generalmente creía que desencadenaría un “renacimiento de Plasma” en el futuro y, como resultado, las soluciones DA fuera del ecosistema Ethereum, como Celestia, podrían ser suprimidas. Plasma no tiene requisitos estrictos para DA. Sin embargo, según la investigación del autor de este artículo, Redstone no se ajusta al marco general de la solución Plasma. Su afirmación de estar “inspirado en Plasma” puede en realidad seguir los temas candentes del artículo de Vitalik. No es que Vitalik realmente quiera defender a Redstone. Además, el plan de desafío DA de Redstone es bastante similar al plan lanzado por el proyecto de Capa 2 Metis en abril de 2022, excepto que el orden de los dos pasos de actualizar Stateroot y publicar datos DA es diferente. Entonces, la situación real es que es posible que todos hayan "sobreinterpretado" Redstone. A continuación se explicará a los lectores mediante un razonamiento simpleEl principio de Plasma y por qué no es compatible con los contratos inteligentes y Defi, y qué es exactamente Redstone.

Plasma: Se requieren retiros urgentes en caso de un ataque de retención de datos

La historia de Plasma se remonta al auge de las ICO de Ethereum en 2017. En ese momento, la demanda de transacciones de los usuarios de Ethereum se disparó y ETH, que tenía un TPS bajo, se vio abrumado. En este momento, se lanzó la primera versión teórica de Plasma, que proponía un plan de expansión de segunda capa que puede manejar "casi todos los escenarios financieros del mundo". En pocas palabras, Plasma es una solución de expansión que solo publica el encabezado del bloque/raíz Merkle de Layer2 en Layer1. La parte de los datos (datos DA) que no sea el encabezado del bloque/Merkle Root solo se publica fuera de la cadena. Si el Merkle Root emitido por el clasificador/Operador de Plasma en L1 está asociado con una transacción no válida (error de firma digital, etc.) , el usuario correspondiente puede enviar un certificado de fraude para demostrar que la raíz enviada por el clasificador está asociada con una transacción no válida. Pero el problema es que para emitir un certificado de fraude, es necesario asegurarse de que no se retengan datos DA, pero Plasma no tiene requisitos estrictos en la capa DA y no puede garantizar que los usuarios o los nodos L2 puedan recibir datos. Si el secuenciador se inicia en un momento determinado, los ataques de retención de datos (también conocidos como problemas de disponibilidad de datos) solo publican nuevos encabezados de bloque/raíces de Merkle, pero no publican los cuerpos de bloque correspondientes. Sin la capacidad de verificar si el encabezado/raíz del bloque es válido, los usuarios solo pueden utilizar de forma predeterminada el secuenciador "desesperado" y retirar activos de la Capa 2 a la Capa 1 a través de un mecanismo de salida de emergencia llamado "Salir del juego".

Este paso requiere que el usuario envíe Merkle Proof para demostrar que efectivamente tiene la cantidad correspondiente de activos en L2. A esto lo podemos llamar “Prueba de bienes”. Lo interesante es que el modo Exit Game de Plasma y el modo de trampilla de escape de ZK Rollup son diferentes. Los usuarios de ZK Rollup deben enviar la Prueba Merkle correspondiente al Stateroot válido más reciente, mientras que los usuarios de Plasma pueden enviar la Prueba correspondiente a Merkle Root hace mucho tiempo. ¿Por qué está diseñado así? Solo porque el Stateroot enviado por ZK Rollup será juzgado inmediatamente por el contrato en Layer1 (para determinar si el certificado de validez es válido). Si el Stateroot recién enviado es válido y legal, entonces el usuario debe enviar la Prueba Merkle correspondiente al Stateroot legal para que sirva como certificado de activo. Sin embargo, el contrato Layer1 no puede determinar si el Merkle Root enviado por el secuenciador de Plasma es válido. Solo puede permitir que el nodo L2 inicie activamente un desafío para eliminar raíces no válidas, por lo que habrá un mecanismo de desafío. Esto hace que Plasma y Zk Rollup funcionen de manera muy diferente. Supongamos que el secuenciador acaba de emitir un Merkle Root 101 no válido y lanzó un ataque de retención de datos para que el nodo L2 no pueda probar que la raíz número 101 no es válida. En este momento, el usuario puede enviar una prueba merkle correspondiente a la raíz número 100 o anterior. Retirar tus propios bienes.

Por supuesto, hay un problema que debe resolverse aquí, es decir, un usuario puede enviar un certificado de activo correspondiente a la raíz número 30 o anterior y solicitar retirar activos a la Capa 1. Sin embargo, el estado patrimonial de esta persona puede cambiar después de que se libere la raíz número 30. En otras palabras, lo que presentó fue una prueba de activos desactualizada, que es un típico ataque de doble gasto/doble gasto.

En este sentido, Plasma permite que cualquier persona presente una prueba de fraude en la situación anterior, señalando que la “prueba de activos” presentada por un usuario que inició una declaración de retiro está desactualizada. Al introducir este "cualquiera puede impugnar el reclamo de retiro de otra persona", Plasma no necesita manejar solicitudes de retiro de emergencia como ZK Rollup. Pero todavía existe la posibilidad, es decir, el secuenciador primero transfiere los activos de otras personas a su propia cuenta L2 y luego lanza un ataque de retención de datos para que personas ajenas no puedan cuestionar su comportamiento de trampa. Posteriormente, el secuenciador inició un retiro de emergencia de su propia cuenta y presentó una "prueba de activos" afirmando que efectivamente era propietario de estos activos en L2. Obviamente, en este momento, debido a que falta un registro histórico, la gente no puede probar directamente que existe un problema con el origen de los activos del clasificador. Entonces, ¿qué deberías hacer en esta situación? Las primeras versiones de Plasma, como Plasma MVP, tuvieron esto en cuenta y propusieron una "Prioridad de retirada". Si el certificado de activo presentado por una persona corresponde a una raíz anterior, se procesará primero su solicitud de retiro.

Si el secuenciador realiza el comportamiento de trampa mencionado anteriormente e inicia un retiro al enviar la raíz No. 101, entonces el usuario puede enviar un certificado de activo correspondiente a la raíz No. 99 o anterior para realizar un retiro de emergencia. Obviamente, mientras el clasificador no pueda alterar los registros históricos que se han publicado en la Capa 1, el usuario tendrá una manera de escapar. Pero Plasma todavía tiene un error fatal: mientras el secuenciador inicie la retención de datos, la gente tiene que confiar en sobre retiros de emergencia (también conocido como Exit Game) para garantizar la seguridad de los activos. Si una gran cantidad de usuarios retira dinero colectivamente en un corto período de tiempo, la Capa 1 fácilmente no podrá manejarlo; lo que es más grave es, ¿quién debería retirar los activos registrados en el contrato Defi a la Capa 1? Supongamos que alguien carga 100 ETH en el grupo LP de DEX, y luego el secuenciador de Plasma falla o hace algo malo, y la gente necesita retirar fondos con urgencia. En este momento, los 100 ETH del usuario todavía están controlados por el contrato DEX. En este momento, ¿cuáles deberían ser estos activos? ¿Quién mencionó Layer1? En realidad, la mejor manera es permitir que los usuarios canjeen sus activos del grupo DEX primero y luego permitir que los usuarios transfieran el dinero a L1 ellos mismos. Sin embargo, el problema es que el secuenciador de plasma no funcionó correctamente o hizo algo malo y los usuarios no pueden canjear los activos. operación. Pero si permitimos que el propietario del contrato DEX eleve los activos controlados por el contrato a L1, obviamente le dará al propietario del contrato la propiedad de los activos. Puede llevar estos activos a L1 y huir en cualquier momento. ¿No sería esto terrible? Entonces, al final, cómo lidiar con estas “propiedades públicas” controladas por contratos Defi es una gran sorpresa. Si seguimos el consenso social, parece posible reconstruir un contrato espejo en la Capa 1 que mapee el contrato defi en la Capa 2, pero esto introducirá problemas considerables y aumentará los costos de oportunidad. ¿Quién votará para decidir cómo deshacerse del contrato espejo? Será un gran problema. En realidad, se trata del problema de la distribución del poder público. Los ladrones habían dicho anteriormente en una entrevista: “Es difícil crear cosas nuevas en cadenas públicas de alto rendimiento, los contratos inteligentes implican la distribución de energía”.Así se menciona en el artículo.

Por supuesto, Vitalik también señaló esto en su reciente artículo “Salir de los juegos para validiums de EVM: el regreso de Plasma”, y enfatizó que este es uno de los factores que hace que Plasma no sea amigable con los contratos inteligentes. Variantes de Plasma conocidas en el pasado Como Plasma MVP y Plasma Cash, utilizaron UTXO o modelos similares para reemplazar el modelo de dirección de cuenta de Ethereum y no admitieron contratos inteligentes, lo que puede evitar el problema de "distribución de propiedad de activos" mencionado anteriormente. Aunque la propiedad de cada UTXO pertenece al propio usuario, el propio UTXO también tiene muchos defectos y no es compatible con los contratos inteligentes. Por lo tanto, la solución Plasma es más adecuada para pagos sencillos o intercambios de libros de pedidos. Después de eso,Con la popularidad de ZK Rollup, el propio Plasma también se ha retirado del escenario de la historia.Porque Rollup no tiene el problema de retención de datos de Plasma. Si el secuenciador de ZK Rollup lanza un ataque de retención de datos y solo envía Stateroot pero no datos DA a la cadena ETH, dicha raíz será considerada inválida y rechazada directamente por el contrato del Verificador en L1. Por lo tanto, los datos DA correspondientes al Stateroot legal de ZK Rollup deben estar disponibles en la cadena ETH. Eso es todo. No se puede "publicar solo el encabezado del bloque o la raíz de Merkle, pero no el cuerpo del bloque correspondiente", lo que significa que puede resolver el problema de disponibilidad de datos/ataque de retención de datos. Al mismo tiempo, se pueden verificar los datos de DA anteriores de Rollup. Ethereum y cualquiera puede iniciar nodos de Capa 2 a través de los registros históricos en la cadena ETH, lo que reducirá en gran medida la dificultad de las soluciones de secuenciador descentralizadas e incluso sin permiso. Por el contrario, Plasma no tiene requisitos estrictos para DA y es más difícil implementar un clasificador descentralizado (para implementar un clasificador descentralizado reemplazable, primero debemos asegurarnos de que todos los nodos L2 reconozcan el mismo bloque, lo que plantea requisitos para la implementación de DA). .). Además, si el secuenciador de ZK Rollup intenta incluir transacciones no válidas en bloques de Capa 2, no lo conseguirá. Esto está garantizado por el principio de prueba de validez. En el análisis final, el espacio maligno del clasificador ZK Rollup es mucho más pequeño que el de Plasma; como máximo, puede detener las actualizaciones de Stateroot, lo que equivale a cerrar el nivel UX, o denegar las solicitudes de ciertos usuarios, comúnmente conocido como revisión de transacciones. al mismo tiempo, si el clasificador falla en el esquema de resumen, será más fácil para otros nodos reemplazarlo. Un resumen ideal puede reducir la probabilidad de activar el modo de juego Salir en Plasma a 0 (llamado trampilla de escape en ZK Rollup ).

(La columna Fallo del proponente en L2BEAT muestra cómo responde cada solución L2 al fallo del secuenciador. Self Propose a menudo se refiere a otros nodos que pueden reemplazar el secuenciador actualmente inactivo)

Hoy en día, casi ningún equipo en el ecosistema Ethereum sigue la ruta de Plasma, y casi todos los proyectos de Plasma han nacido muertos.

(Vitalik explica por qué ZK Rollup es superior a Plasma, mencionando la operación del secuenciador sin permiso y problemas de DA)

Qué es Redstone: No es Plasma, sino una variante de Optimium

Arriba explicamos brevemente Plasma y los breves factores por los que fue reemplazado por Rollup. En cuanto a Redstone, también debes haber visto la diferencia entre este y Plasma: Redstone puede resolver el problema de los ataques de retención de datos. Por ejemplo, no lanzará un nuevo estado raíz de inmediato. En su lugar, primero publicará los datos DA originales bajo la cadena ETH, y luego usará el hash de datos de los datos DA como un compromiso de credencial asociado y lo publicará en la cadena ETH, diciendo que los ha publicado bajo la cadena. Los datos completos correspondientes al segmento datahash.

(Explicación oficial de Redstone sobre su plan para prevenir ataques de retención de datos)

Cualquiera puede iniciar un desafío, diciendo que el clasificador de Redstone no publicó los datos originales correspondientes a este datahash fuera de la cadena. En este momento, el secuenciador necesita publicar los datos correspondientes al hash de datos en la cadena para enfrentar los desafíos de los escépticos. Si el secuenciador no publica los datos en la cadena ETH a tiempo después de ser cuestionado, el hash/compromiso de datos que publicó anteriormente considerarse inválido. Si el clasificador responde a la solicitud del retador a tiempo, el retador puede obtener los datos DA originales correspondientes al hash de datos a tiempo. Al final, todos los nodos L2 básicamente pueden obtener los datos DA requeridos para resolver el problema de los ataques de retención de datos. Por supuesto, el retador primero debe pagar una tarifa, que es aproximadamente igual al costo de que el secuenciador publique los datos DA originales en la cadena ETH. Esta medida tiene como objetivo evitar que desafiantes maliciosos desafíen el secuenciador sin costo alguno, provocando que este último sufra pérdidas. . Por último, cuando finalice el período de desafío para el hash de datos, el clasificador liberará la raíz de estado correspondiente, es decir, la raíz obtenida después de ejecutar la secuencia de transacciones contenida en los datos DA correspondientes al hash de datos. En este punto, los nodos L2 pueden utilizar el sistema a prueba de fraude para cuestionar esas raíces no válidas. Si el clasificador no publica los datos DA originales correspondientes a tiempo después de que se cuestione un hash de datos anterior, incluso si el clasificador libera posteriormente el stateroot correspondiente a este hash de datos, no será válido de forma predeterminada. PorqueRedstone primero publica datos DA y luego libera el Stateroot efectivo correspondiente, resolviendo directamente el problema de los ataques de retención de datos.(El El clasificador solo publica datos raíz y no datos DA). Obviamente, este modo es diferente del Optimium ordinario (OP Rollup que no usa Ethereum para implementar DA, como Arbitrum Nova). Optimium generalmente depende del comité DAC fuera de la cadena para garantizar la disponibilidad de los datos. DAC envía un txn con firma múltiple al cadena a intervalos regulares. Después de que el contrato acumulativo en Layer1 reciba el txn multifirmado, el secuenciador publicará de forma predeterminada el último lote de datos DA fuera de la cadena.

(Fuente: L2beat)

Por ejemplo, Metis y Arbitrum Nova envían Stateroot y datahash al mismo tiempo. Si alguien piensa que el clasificador ha retenido datos DA, intentará cuestionarlo y el clasificador enviará los datos DA correspondientes al hash de datos a la cadena. entonces,La diferencia clave entre Redstone y Metis está en este paso:El primero lanza datahash primero y luego libera stateroot después de que finaliza el período de desafío DA; Metis lanza stateroot y datahash al mismo tiempo. Si alguien inicia un desafío, los datos de DA se cargan en la cadena. Obviamente, la solución de Redstone es más segura, porque bajo la solución de Metis, si el clasificador nunca responde a la solicitud de datos de DA del retador, el problema del ataque de retención de datos no se puede resolver rápidamente. Sólo podemos confiar en las retiradas de emergencia y en el consenso social, o dejar que otros nodos se hagan cargo del clasificador actual. ;

Pero en Redstone, si el clasificador retiene datos, el stateroot emitido por él se considerará directamente inválido, por lo que los datos stateroot y DA están vinculados. Esto permite a Redstone obtener una garantía DA más cercana a la de Rollup, que es esencialmente un variante de Optimium que es superior a Arbitrum Nova y Metis.

Descargo de responsabilidad:

1. Este artículo se reimprime de [极客web3]. Todos los derechos de autor pertenecen al autor original [Fausto]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.