Recientemente, un proyecto llamado Redstone se ha convertido en un tema candente. ** Esta instalación de capa 2 lanzada por el equipo de Lattice se lanzó oficialmente el 15 de noviembre y ahora se ha lanzado en la red de pruebas. Curiosamente, el equipo de Lattice afirma que "Redstone es una cadena Alt-DA inspirada en el plasma".
Justo un día antes del lanzamiento de Redstone, Vitalik publicó el artículo "Exit games for EVM validiums: the return of Plasma", en el que repasaba brevemente la solución técnica "Plasma" que había desaparecido del ecosistema Ethereum, y señalaba que las pruebas de validez (confundidas con ZK Proof) podrían introducirse para resolver el problema de Plasma.
En este sentido, muchos amigos creen que Vitalik publicó este artículo con el fin de darle una plataforma a Redstone, e incluso en la comunidad geek Web3, algunas personas dicen que Vitalik no ha invertido en Redstone. Junto con la ebullición de la "disputa de la definición de la capa 2 de Ethereum" en el rumor anterior, se creía ampliamente que se desencadenaría el próximo "renacimiento de Plasma", y que las soluciones de DA fuera del ecosistema de Ethereum, como Celestia, podrían suprimirse, porque Plasma no tiene requisitos estrictos para DA. **
Sin embargo, de acuerdo con la investigación del autor de este artículo, Redstone no encaja en el marco general de la solución de plasma, y su afirmación de estar "inspirada en el plasma" tiene la posibilidad de frotar el calor del artículo de Vitalik, en lugar de que Vitalik realmente quiera representar a Redstone. Además, el desafío de DA de Redstone es similar al proyecto de capa 2 que Metis lanzó en abril de 2022, excepto que el orden de actualización de Stateroot y publicación de los datos de DA es diferente.
Por lo tanto, la situación real es que es posible que haya "sobreinterpretado" a Redstone. El siguiente es un razonamiento simple para explicar cómo funciona Plasma, por qué no es amigable con los contratos inteligentes y Defi, y qué es exactamente Redstone. **
Plasma: Retirada urgente en caso de ataque de retención de datos
La historia del plasma se remonta al auge de Ethereum IC0 en 2017, cuando la demanda de transacciones de los usuarios de Ethereum se disparó y ETH con un TPS bajo se vio abrumado. En esta coyuntura, se lanzó la primera versión teórica de Plasma, que proponía un esquema de escalado de capa 2 que podría manejar "casi todos los escenarios financieros del mundo".
En pocas palabras, Plasma es una solución de escalado que solo publica el encabezado de bloque de capa 2 / raíz de Merkle en la capa 1, y la parte de los datos fuera del encabezado de bloque / raíz de Merkle (datos DA) solo se publica fuera de la cadena. **Si la raíz de Merkle publicada por el secuenciador/operador de plasma en L1 está asociada a una transacción no válida (por ejemplo, un error de firma digital), el usuario puede enviar un certificado de fraude para demostrar que la raíz enviada por el secuenciador está asociada a una transacción no válida.
El problema es que para emitir pruebas de fraude, es necesario asegurarse de que los datos de DA no se retengan, pero Plasma no tiene requisitos estrictos para la capa de DA y no puede garantizar que los usuarios o los nodos L2 puedan recibir datos. Si el secuenciador lanza un ataque de retención de datos (también conocido como problema de disponibilidad de datos) en un momento determinado, y solo publica un nuevo encabezado de bloque/raíz de Merkle, pero no publica el cuerpo de bloque correspondiente, lo que hace imposible verificar si el encabezado/raíz del bloque es válido, el usuario solo puede usar el secuenciador de forma predeterminada como "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 una prueba de Merkle para demostrar que tiene una cantidad correspondiente de activos en L2, que podemos llamar "Prueba de activos". Curiosamente, el juego de salida de Plasma no es lo mismo que el modo Escape Pod de ZK Rollup, donde los usuarios de ZK Rollup deben enviar una prueba de Merkle correspondiente al Stateroot válido más reciente, mientras que los usuarios de Plasma pueden enviar una prueba correspondiente a una raíz de Merkle de hace mucho tiempo.
¿Por qué está diseñado de esta manera? Es solo que el Stateroot presentado por el ZK Rollup será juzgado inmediatamente por el contrato en la Capa 1 (para determinar si la prueba de validez es válida). Si el Stateroot recién enviado es válido y legítimo, entonces el usuario debe presentar la prueba de Merkle correspondiente al Stateroot válido como prueba de activos.
Sin embargo, la Raíz de Merkle presentada por el secuenciador de Plasma, el contrato de Capa1 no puede juzgar si es válida o no, y solo puede dejar que el nodo L2 tome la iniciativa de desafiar para excluir la Raíz inválida, por lo que habrá un mecanismo de desafío, lo que hace que el funcionamiento de Plasma y Zk Rollup sea muy diferente. **
Supongamos que el secuenciador acaba de liberar una raíz de Merkle 101 no válida y ha lanzado un ataque de retención de datos, de modo que el nodo L2 no puede demostrar que la raíz 101 no es válida, entonces el usuario puede enviar la prueba de merkle correspondiente a la raíz 100 o a la raíz anterior y retirar sus activos.
Por supuesto, hay un problema que debe resolverse aquí, es decir, un usuario puede enviar un certificado de activo correspondiente a la raíz 30 o anterior y solicitar retirar el activo a la Capa 1, pero el estado del activo de esta persona puede cambiar después de la liberación de la raíz 30. En otras palabras, presenta una prueba obsoleta de activos, que es un típico ataque de doble gasto/doble gasto. **
En respuesta, Plasma permite que cualquier persona envíe un certificado de fraude para los casos anteriores, indicando que la "prueba de equidad" presentada por un usuario que inició un reclamo de retiro está desactualizada. Al introducir esto "cualquiera puede impugnar la declaración de retirada de otra persona", Plasma no necesita gestionar solicitudes de retirada de emergencia como ZK Rollup.
Pero todavía existe la posibilidad de que el clasificador transfiera los activos de otra persona a su propia cuenta L2 antes de lanzar un ataque de retención de datos que haga imposible que personas ajenas cuestionen sus trampas. Después de eso, la propia cuenta del secuenciador inicia un retiro de emergencia, presentando una "prueba de activos" afirmando que realmente posee los activos en L2.
Obviamente, debido a la falta de un pedazo de historia, no hay forma de probar directamente que la fuente de activos del secuenciador es problemática. Las versiones anteriores de Plasma, como Plasma MVP, tuvieron esto en cuenta y establecieron una "prioridad de retirada". Si una persona presenta una prueba de activos correspondiente a root anteriormente, se priorizará su solicitud de retiro.
Si el secuenciador hace trampa e inicia un retiro al enviar el número raíz 101, el usuario puede enviar una prueba de los activos correspondientes al número raíz 99 o anterior para realizar un retiro de emergencia. Obviamente, siempre que el secuenciador no pueda manipular el historial que se ha publicado en la Capa 1, el usuario tiene una forma de escapar.
Pero Plasma todavía tiene un error fatal: siempre que el secuenciador inicie la retención de datos, las personas tienen que confiar en retiros de emergencia (también conocidos como Exit Game) para garantizar la seguridad de los activos, y si una gran cantidad de usuarios se retiran colectivamente en un corto período de tiempo, la Capa 1 es fácil de manejar;
Supongamos que alguien recarga 100 ETH al pool de LP del DEX, y luego el secuenciador del Plasma falla o hace el mal, y la gente necesita 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 es permitir que los usuarios canjeen sus activos del grupo DEX primero, y luego dejar que los usuarios retiren su dinero a L1 ellos mismos, pero el problema es que el secuenciador de Plasma funciona mal/se corrompe y los usuarios no pueden canjear sus activos. Pero, ¿no sería terrible si permitiéramos que el propietario del contrato DEX llevara los activos controlados por el contrato a L1, lo que obviamente le daba al propietario del contrato la propiedad de los activos, y podría aumentar estos activos a L1 en cualquier momento y huir?
Así que, al final, cómo lidiar con esta "propiedad pública" respaldada por los contratos Defi es un gran trueno. ** Si sigue el consenso social, parece que está bien reconstruir un contrato espejo en la Capa 1 que refleje el contrato defi en la Capa 2, pero esto introducirá un gran problema, aumentará el costo de oportunidad y quién votará sobre la eliminación del contrato espejo también será un gran problema. En realidad, esto implica el problema de la distribución del poder público, del que Xiangma ha hablado anteriormente en una entrevista "Es difícil para las cadenas públicas de alto rendimiento hacer cosas nuevas, y los contratos inteligentes implican la distribución de energía.
Por supuesto, Vitalik también señala esto en su reciente artículo "Exit games for EVM validiums: the return of Plasma", y destaca esto como uno de los factores que hacen que Plasma sea poco amigable con los contratos inteligentes. ** En el pasado, las variantes conocidas de Plasma, como Plasma MVP y Plasma Cash, usaban UTXO o modelos similares para reemplazar el modelo de dirección de cuenta de Ethereum, y no admitían contratos inteligentes, lo que puede evitar el problema de "distribución de la propiedad de activos" mencionado anteriormente, aunque la propiedad de cada UTXO pertenece al usuario, pero UTXO en sí tiene muchos defectos y no es amigable con los contratos inteligentes. Por lo tanto, la solución Plasma es la más adecuada para pagos sencillos o intercambios de carteras de pedidos.
Más tarde, con la popularidad de ZK Rollup, el propio Plasma también se retiró del escenario de la historia, porque Rollup no tenía el problema de la retención de datos de Plasma. Si el secuenciador del ZK Rollup lanza un ataque de retención de datos y solo envía el Stateroot a la cadena ETH sin datos de DA, dicha raíz se considerará inválida y rechazada por el contrato del verificador en L1. Por lo tanto, los datos de DA correspondientes al Stateroot legal de ZK Rollup deben estar disponibles en la cadena ETH. De esta manera, no hay "solo publique el encabezado del bloque o la raíz merkle, pero no el cuerpo del bloque correspondiente", es decir, se puede resolver el problema de disponibilidad de datos/ataque de retención de datos. **
Al mismo tiempo, los datos anteriores de DA de Rollups están disponibles en Ethereum, y cualquiera puede iniciar nodos de capa 2 a través de la historia de la cadena ETH, lo que reduce en gran medida la dificultad de los esquemas de secuenciadores descentralizados o incluso sin permisos. Por el contrario, Plasma no tiene requisitos estrictos para DA, y es más difícil implementar un secuenciador descentralizado (para implementar un secuenciador descentralizado reemplazable, primero debe asegurarse 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 del ZK Rollup intenta incluir transacciones no válidas en el bloque de capa 2, no tendrá éxito, lo que está garantizado por el principio de prueba de validez.
Al final del día, el secuenciador ZK Rollup tiene un margen de acción mucho más pequeño que Plasma: en el mejor de los casos, puede detener las actualizaciones de Stateroot, ser el equivalente al tiempo de inactividad a nivel de UX o denegar ciertas solicitudes de los usuarios, lo que se conoce coloquialmente como censura de transacciones. Al mismo tiempo, si el secuenciador falla en el esquema Rollup, será más fácil que otros nodos lo reemplacen. **Idealmente, la probabilidad de activar el modo de juego Salir en Plasma se puede reducir a 0 (llamado cápsula de escape en ZK Rollup).
(La columna Proposser Failure en L2BEAT muestra cómo cada solución L2 puede lidiar con las fallas del secuenciador, Self Pose a menudo se refiere a otros nodos que pueden reemplazar el secuenciador que está actualmente inactivo)**
Hoy en día, casi no hay equipos en el ecosistema de Ethereum que todavía se adhieran a la ruta de Plasma, y casi todos los proyectos de Plasma nacen muertos.
(Vitalik explica por qué ZK Rollup es superior a Plasma, mencionando el funcionamiento sin permisos del secuenciador y los problemas de DA)
Qué es Redstone: No es Plasma, es una variante de Optimium****
Más arriba explicamos brevemente Plasma y las razones por las que se sustituye por Rollup, y en cuanto a Redstone, también debes haber visto la diferencia entre él y Plasma: Redstone puede resolver el problema de los ataques de retención de datos,** Por ejemplo, no liberará inmediatamente un nuevo stateroot, sino que primero publicará los datos de DA originales fuera de la cadena y, a continuación, publicará el datahash de los datos de DA en la cadena ETH como un compromiso de credencial asociado, diciendo que ha publicado los datos completos correspondientes a este datahash fuera de la cadena.
(Explicación oficial de Redstone de su propio plan para evitar ataques de retención de datos)**
Cualquiera puede desafiar al secuenciador de Redstone para que diga que no publica los datos sin procesar para este hash de datos fuera de la cadena. En este punto, el secuenciador necesita publicar los datos correspondientes al datahash en la cadena para cumplir con el desafío del interrogador. ** Si el secuenciador no publica datos en la cadena ETH de manera oportuna después de haber sido impugnado, su datahash/compromiso publicado anteriormente se considerará inválido.
Si el secuenciador responde a la solicitud del impugnador de manera oportuna, el retador puede obtener los datos de DA originales correspondientes al hash de datos a tiempo. Eventualmente, todos los nodos L2 pueden obtener los datos DA necesarios para resolver el problema de los ataques de retención de datos. Por supuesto, el propio retador debe pagar una tarifa que es aproximadamente igual al costo de que el secuenciador publique los datos DA sin procesar en la cadena ETH, para evitar que los retadores malintencionados desafíen al secuenciador sin costo alguno y causen que este último incurra en pérdidas.
Finalmente, cuando finalice el período de desafío para datahash, el secuenciador publicará el stateroot correspondiente, que es la raíz obtenida después de ejecutar la secuencia de transacciones contenida en los datos de DA correspondientes al datahash. En este punto, el nodo L2 puede usar el sistema a prueba de fraude para desafiar esas raíces no válidas. Si el secuenciador no publica los datos de DA originales correspondientes a tiempo después de que se impugne un hash de datos, el secuenciador no será válido de forma predeterminada, incluso si la raíz de estado correspondiente al hash de datos se publica más adelante.
Dado que Redstone publica primero los datos de DA y luego publica el Stateroot válido correspondiente, resuelve directamente el problema de los ataques de retención de datos (el secuenciador solo publica datos de raíz pero no de DA).
Obviamente, este modelo es diferente del Optimium ordinario (OP Rollup de DA sin Ethereum, como Arbitrum Nova), Optimium generalmente se basa en comités DAC fuera de la cadena para garantizar la disponibilidad de los datos, DAC envía un txn multi-Sig a la cadena de vez en cuando, y el contrato Rollup en la Capa 1 se establecerá de forma predeterminada en el secuenciador que ha liberado el último lote de datos DA fuera de la cadena después de recibir el txn multi-Sig.
(图源:L2beat)
Mientras que Metis y Arbitrum Nova envían Stateroot y datahash al mismo tiempo, si alguien cree que el secuenciador retiene datos de DA, intentará lanzar un desafío y el secuenciador enviará los datos de DA correspondientes al datahash a la cadena.
Por lo tanto, la diferencia clave entre Redstone y Metis es la siguiente: el primero publica primero el datahash y espera al final del período de desafío de DA antes de liberar el stateroot, mientras que Metis publica tanto el stateroot como el datahash, y 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 el esquema de Metis, si el secuenciador no responde a la solicitud del retador de datos de DA, el problema del ataque de retención de datos no se puede resolver rápidamente, y la única forma de confiar en los retiros de emergencia y el consenso social es dejar que otros nodos se hagan cargo del secuenciador actual;
Sin embargo, en el caso de Redstone, si el secuenciador se dedica a la retención de datos, el stateroot liberado por él se considera directamente inválido, por lo que los datos stateroot y DA están enlazados, lo que permite a Redstone obtener garantías de DA que están más cerca de Rollup, que es esencialmente una variante superior de Optimium que Arbitrum Nova y Metis.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Restone: No es Plasma, sino la variante Optimium
Autor: Faust, geek web3***
Recientemente, un proyecto llamado Redstone se ha convertido en un tema candente. ** Esta instalación de capa 2 lanzada por el equipo de Lattice se lanzó oficialmente el 15 de noviembre y ahora se ha lanzado en la red de pruebas. Curiosamente, el equipo de Lattice afirma que "Redstone es una cadena Alt-DA inspirada en el plasma".
Justo un día antes del lanzamiento de Redstone, Vitalik publicó el artículo "Exit games for EVM validiums: the return of Plasma", en el que repasaba brevemente la solución técnica "Plasma" que había desaparecido del ecosistema Ethereum, y señalaba que las pruebas de validez (confundidas con ZK Proof) podrían introducirse para resolver el problema de Plasma.
En este sentido, muchos amigos creen que Vitalik publicó este artículo con el fin de darle una plataforma a Redstone, e incluso en la comunidad geek Web3, algunas personas dicen que Vitalik no ha invertido en Redstone. Junto con la ebullición de la "disputa de la definición de la capa 2 de Ethereum" en el rumor anterior, se creía ampliamente que se desencadenaría el próximo "renacimiento de Plasma", y que las soluciones de DA fuera del ecosistema de Ethereum, como Celestia, podrían suprimirse, porque Plasma no tiene requisitos estrictos para DA. **
Sin embargo, de acuerdo con la investigación del autor de este artículo, Redstone no encaja en el marco general de la solución de plasma, y su afirmación de estar "inspirada en el plasma" tiene la posibilidad de frotar el calor del artículo de Vitalik, en lugar de que Vitalik realmente quiera representar a Redstone. Además, el desafío de DA de Redstone es similar al proyecto de capa 2 que Metis lanzó en abril de 2022, excepto que el orden de actualización de Stateroot y publicación de los datos de DA es diferente.
Por lo tanto, la situación real es que es posible que haya "sobreinterpretado" a Redstone. El siguiente es un razonamiento simple para explicar cómo funciona Plasma, por qué no es amigable con los contratos inteligentes y Defi, y qué es exactamente Redstone. **
Plasma: Retirada urgente en caso de ataque de retención de datos
La historia del plasma se remonta al auge de Ethereum IC0 en 2017, cuando la demanda de transacciones de los usuarios de Ethereum se disparó y ETH con un TPS bajo se vio abrumado. En esta coyuntura, se lanzó la primera versión teórica de Plasma, que proponía un esquema de escalado de capa 2 que podría manejar "casi todos los escenarios financieros del mundo".
En pocas palabras, Plasma es una solución de escalado que solo publica el encabezado de bloque de capa 2 / raíz de Merkle en la capa 1, y la parte de los datos fuera del encabezado de bloque / raíz de Merkle (datos DA) solo se publica fuera de la cadena. **Si la raíz de Merkle publicada por el secuenciador/operador de plasma en L1 está asociada a una transacción no válida (por ejemplo, un error de firma digital), el usuario puede enviar un certificado de fraude para demostrar que la raíz enviada por el secuenciador está asociada a una transacción no válida.
El problema es que para emitir pruebas de fraude, es necesario asegurarse de que los datos de DA no se retengan, pero Plasma no tiene requisitos estrictos para la capa de DA y no puede garantizar que los usuarios o los nodos L2 puedan recibir datos. Si el secuenciador lanza un ataque de retención de datos (también conocido como problema de disponibilidad de datos) en un momento determinado, y solo publica un nuevo encabezado de bloque/raíz de Merkle, pero no publica el cuerpo de bloque correspondiente, lo que hace imposible verificar si el encabezado/raíz del bloque es válido, el usuario solo puede usar el secuenciador de forma predeterminada como "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 una prueba de Merkle para demostrar que tiene una cantidad correspondiente de activos en L2, que podemos llamar "Prueba de activos". Curiosamente, el juego de salida de Plasma no es lo mismo que el modo Escape Pod de ZK Rollup, donde los usuarios de ZK Rollup deben enviar una prueba de Merkle correspondiente al Stateroot válido más reciente, mientras que los usuarios de Plasma pueden enviar una prueba correspondiente a una raíz de Merkle de hace mucho tiempo.
¿Por qué está diseñado de esta manera? Es solo que el Stateroot presentado por el ZK Rollup será juzgado inmediatamente por el contrato en la Capa 1 (para determinar si la prueba de validez es válida). Si el Stateroot recién enviado es válido y legítimo, entonces el usuario debe presentar la prueba de Merkle correspondiente al Stateroot válido como prueba de activos.
Sin embargo, la Raíz de Merkle presentada por el secuenciador de Plasma, el contrato de Capa1 no puede juzgar si es válida o no, y solo puede dejar que el nodo L2 tome la iniciativa de desafiar para excluir la Raíz inválida, por lo que habrá un mecanismo de desafío, lo que hace que el funcionamiento de Plasma y Zk Rollup sea muy diferente. **
Supongamos que el secuenciador acaba de liberar una raíz de Merkle 101 no válida y ha lanzado un ataque de retención de datos, de modo que el nodo L2 no puede demostrar que la raíz 101 no es válida, entonces el usuario puede enviar la prueba de merkle correspondiente a la raíz 100 o a la raíz anterior y retirar sus activos.
Por supuesto, hay un problema que debe resolverse aquí, es decir, un usuario puede enviar un certificado de activo correspondiente a la raíz 30 o anterior y solicitar retirar el activo a la Capa 1, pero el estado del activo de esta persona puede cambiar después de la liberación de la raíz 30. En otras palabras, presenta una prueba obsoleta de activos, que es un típico ataque de doble gasto/doble gasto. **
En respuesta, Plasma permite que cualquier persona envíe un certificado de fraude para los casos anteriores, indicando que la "prueba de equidad" presentada por un usuario que inició un reclamo de retiro está desactualizada. Al introducir esto "cualquiera puede impugnar la declaración de retirada de otra persona", Plasma no necesita gestionar solicitudes de retirada de emergencia como ZK Rollup.
Pero todavía existe la posibilidad de que el clasificador transfiera los activos de otra persona a su propia cuenta L2 antes de lanzar un ataque de retención de datos que haga imposible que personas ajenas cuestionen sus trampas. Después de eso, la propia cuenta del secuenciador inicia un retiro de emergencia, presentando una "prueba de activos" afirmando que realmente posee los activos en L2.
Obviamente, debido a la falta de un pedazo de historia, no hay forma de probar directamente que la fuente de activos del secuenciador es problemática. Las versiones anteriores de Plasma, como Plasma MVP, tuvieron esto en cuenta y establecieron una "prioridad de retirada". Si una persona presenta una prueba de activos correspondiente a root anteriormente, se priorizará su solicitud de retiro.
Si el secuenciador hace trampa e inicia un retiro al enviar el número raíz 101, el usuario puede enviar una prueba de los activos correspondientes al número raíz 99 o anterior para realizar un retiro de emergencia. Obviamente, siempre que el secuenciador no pueda manipular el historial que se ha publicado en la Capa 1, el usuario tiene una forma de escapar.
Pero Plasma todavía tiene un error fatal: siempre que el secuenciador inicie la retención de datos, las personas tienen que confiar en retiros de emergencia (también conocidos como Exit Game) para garantizar la seguridad de los activos, y si una gran cantidad de usuarios se retiran colectivamente en un corto período de tiempo, la Capa 1 es fácil de manejar;
Supongamos que alguien recarga 100 ETH al pool de LP del DEX, y luego el secuenciador del Plasma falla o hace el mal, y la gente necesita 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 es permitir que los usuarios canjeen sus activos del grupo DEX primero, y luego dejar que los usuarios retiren su dinero a L1 ellos mismos, pero el problema es que el secuenciador de Plasma funciona mal/se corrompe y los usuarios no pueden canjear sus activos. Pero, ¿no sería terrible si permitiéramos que el propietario del contrato DEX llevara los activos controlados por el contrato a L1, lo que obviamente le daba al propietario del contrato la propiedad de los activos, y podría aumentar estos activos a L1 en cualquier momento y huir?
Así que, al final, cómo lidiar con esta "propiedad pública" respaldada por los contratos Defi es un gran trueno. ** Si sigue el consenso social, parece que está bien reconstruir un contrato espejo en la Capa 1 que refleje el contrato defi en la Capa 2, pero esto introducirá un gran problema, aumentará el costo de oportunidad y quién votará sobre la eliminación del contrato espejo también será un gran problema. En realidad, esto implica el problema de la distribución del poder público, del que Xiangma ha hablado anteriormente en una entrevista "Es difícil para las cadenas públicas de alto rendimiento hacer cosas nuevas, y los contratos inteligentes implican la distribución de energía.
Por supuesto, Vitalik también señala esto en su reciente artículo "Exit games for EVM validiums: the return of Plasma", y destaca esto como uno de los factores que hacen que Plasma sea poco amigable con los contratos inteligentes. ** En el pasado, las variantes conocidas de Plasma, como Plasma MVP y Plasma Cash, usaban UTXO o modelos similares para reemplazar el modelo de dirección de cuenta de Ethereum, y no admitían contratos inteligentes, lo que puede evitar el problema de "distribución de la propiedad de activos" mencionado anteriormente, aunque la propiedad de cada UTXO pertenece al usuario, pero UTXO en sí tiene muchos defectos y no es amigable con los contratos inteligentes. Por lo tanto, la solución Plasma es la más adecuada para pagos sencillos o intercambios de carteras de pedidos.
Más tarde, con la popularidad de ZK Rollup, el propio Plasma también se retiró del escenario de la historia, porque Rollup no tenía el problema de la retención de datos de Plasma. Si el secuenciador del ZK Rollup lanza un ataque de retención de datos y solo envía el Stateroot a la cadena ETH sin datos de DA, dicha raíz se considerará inválida y rechazada por el contrato del verificador en L1. Por lo tanto, los datos de DA correspondientes al Stateroot legal de ZK Rollup deben estar disponibles en la cadena ETH. De esta manera, no hay "solo publique el encabezado del bloque o la raíz merkle, pero no el cuerpo del bloque correspondiente", es decir, se puede resolver el problema de disponibilidad de datos/ataque de retención de datos. **
Al mismo tiempo, los datos anteriores de DA de Rollups están disponibles en Ethereum, y cualquiera puede iniciar nodos de capa 2 a través de la historia de la cadena ETH, lo que reduce en gran medida la dificultad de los esquemas de secuenciadores descentralizados o incluso sin permisos. Por el contrario, Plasma no tiene requisitos estrictos para DA, y es más difícil implementar un secuenciador descentralizado (para implementar un secuenciador descentralizado reemplazable, primero debe asegurarse 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 del ZK Rollup intenta incluir transacciones no válidas en el bloque de capa 2, no tendrá éxito, lo que está garantizado por el principio de prueba de validez.
Al final del día, el secuenciador ZK Rollup tiene un margen de acción mucho más pequeño que Plasma: en el mejor de los casos, puede detener las actualizaciones de Stateroot, ser el equivalente al tiempo de inactividad a nivel de UX o denegar ciertas solicitudes de los usuarios, lo que se conoce coloquialmente como censura de transacciones. Al mismo tiempo, si el secuenciador falla en el esquema Rollup, será más fácil que otros nodos lo reemplacen. **Idealmente, la probabilidad de activar el modo de juego Salir en Plasma se puede reducir a 0 (llamado cápsula de escape en ZK Rollup).
(La columna Proposser Failure en L2BEAT muestra cómo cada solución L2 puede lidiar con las fallas del secuenciador, Self Pose a menudo se refiere a otros nodos que pueden reemplazar el secuenciador que está actualmente inactivo)**
Hoy en día, casi no hay equipos en el ecosistema de Ethereum que todavía se adhieran a la ruta de Plasma, y casi todos los proyectos de Plasma nacen muertos.
(Vitalik explica por qué ZK Rollup es superior a Plasma, mencionando el funcionamiento sin permisos del secuenciador y los problemas de DA)
Qué es Redstone: No es Plasma, es una variante de Optimium****
Más arriba explicamos brevemente Plasma y las razones por las que se sustituye por Rollup, y en cuanto a Redstone, también debes haber visto la diferencia entre él y Plasma: Redstone puede resolver el problema de los ataques de retención de datos,** Por ejemplo, no liberará inmediatamente un nuevo stateroot, sino que primero publicará los datos de DA originales fuera de la cadena y, a continuación, publicará el datahash de los datos de DA en la cadena ETH como un compromiso de credencial asociado, diciendo que ha publicado los datos completos correspondientes a este datahash fuera de la cadena.
(Explicación oficial de Redstone de su propio plan para evitar ataques de retención de datos)**
Cualquiera puede desafiar al secuenciador de Redstone para que diga que no publica los datos sin procesar para este hash de datos fuera de la cadena. En este punto, el secuenciador necesita publicar los datos correspondientes al datahash en la cadena para cumplir con el desafío del interrogador. ** Si el secuenciador no publica datos en la cadena ETH de manera oportuna después de haber sido impugnado, su datahash/compromiso publicado anteriormente se considerará inválido.
Si el secuenciador responde a la solicitud del impugnador de manera oportuna, el retador puede obtener los datos de DA originales correspondientes al hash de datos a tiempo. Eventualmente, todos los nodos L2 pueden obtener los datos DA necesarios para resolver el problema de los ataques de retención de datos. Por supuesto, el propio retador debe pagar una tarifa que es aproximadamente igual al costo de que el secuenciador publique los datos DA sin procesar en la cadena ETH, para evitar que los retadores malintencionados desafíen al secuenciador sin costo alguno y causen que este último incurra en pérdidas.
Finalmente, cuando finalice el período de desafío para datahash, el secuenciador publicará el stateroot correspondiente, que es la raíz obtenida después de ejecutar la secuencia de transacciones contenida en los datos de DA correspondientes al datahash. En este punto, el nodo L2 puede usar el sistema a prueba de fraude para desafiar esas raíces no válidas. Si el secuenciador no publica los datos de DA originales correspondientes a tiempo después de que se impugne un hash de datos, el secuenciador no será válido de forma predeterminada, incluso si la raíz de estado correspondiente al hash de datos se publica más adelante.
Dado que Redstone publica primero los datos de DA y luego publica el Stateroot válido correspondiente, resuelve directamente el problema de los ataques de retención de datos (el secuenciador solo publica datos de raíz pero no de DA).
Obviamente, este modelo es diferente del Optimium ordinario (OP Rollup de DA sin Ethereum, como Arbitrum Nova), Optimium generalmente se basa en comités DAC fuera de la cadena para garantizar la disponibilidad de los datos, DAC envía un txn multi-Sig a la cadena de vez en cuando, y el contrato Rollup en la Capa 1 se establecerá de forma predeterminada en el secuenciador que ha liberado el último lote de datos DA fuera de la cadena después de recibir el txn multi-Sig.
(图源:L2beat)
Mientras que Metis y Arbitrum Nova envían Stateroot y datahash al mismo tiempo, si alguien cree que el secuenciador retiene datos de DA, intentará lanzar un desafío y el secuenciador enviará los datos de DA correspondientes al datahash a la cadena.
Por lo tanto, la diferencia clave entre Redstone y Metis es la siguiente: el primero publica primero el datahash y espera al final del período de desafío de DA antes de liberar el stateroot, mientras que Metis publica tanto el stateroot como el datahash, y 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 el esquema de Metis, si el secuenciador no responde a la solicitud del retador de datos de DA, el problema del ataque de retención de datos no se puede resolver rápidamente, y la única forma de confiar en los retiros de emergencia y el consenso social es dejar que otros nodos se hagan cargo del secuenciador actual;
Sin embargo, en el caso de Redstone, si el secuenciador se dedica a la retención de datos, el stateroot liberado por él se considera directamente inválido, por lo que los datos stateroot y DA están enlazados, lo que permite a Redstone obtener garantías de DA que están más cerca de Rollup, que es esencialmente una variante superior de Optimium que Arbitrum Nova y Metis.