Salir de los juegos para las validaciones de EVM: el regreso de Plasma

Intermedio3/1/2024, 6:59:34 AM
Este artículo proporciona una explicación de Vitalik sobre el funcionamiento de Plasma, los retos a los que se enfrentan los NFT, los retos a los que se enfrenta la EVM y cómo la prueba de validez puede mitigar muchos de estos problemas.

Un agradecimiento especial a Karl Floersch, Georgios Konstantopoulos y Martin Koppelmann por sus comentarios, revisiones y discusiones.

Plasma es una clase de soluciones de escalado de blockchain que permiten que todos los datos y la computación, excepto los depósitos, retiros y raíces de Merkle, se mantengan fuera de la cadena. Esto abre la puerta a ganancias de escalabilidad muy grandes que no se ven obstaculizadas por la disponibilidad de datos en cadena. Plasma se inventó por primera vez en 2017 y vio muchas iteraciones en 2018, entre las que destacan Plasma Mínimo Viable, Plasma Cash, Plasma Cashflow y Plasma Prime. Desafortunadamente, desde entonces, Plasma ha sido reemplazado en gran medida por los rollups, por razones que tienen que ver principalmente con (i) los grandes costos de almacenamiento de datos del lado del cliente y (ii) las limitaciones fundamentales de Plasma que lo hacen <a href=" https://medium.com/@kelvinfichter /why-is-evm-on-plasma-hard-bf2d99c48df7"> difícil degeneralizar más alláde los pagos.

El advenimiento de las pruebas de validez (también conocidas como ZK-SNARK) nos da una razón para repensar esta decisión. El mayor desafío de hacer que Plasma funcione para los pagos, el almacenamiento de datos del lado del cliente, se puede abordar de manera eficiente con pruebas de validez. Además, las pruebas de validez proporcionan una amplia gama de herramientas que nos permiten crear una cadena similar al plasma que ejecuta una EVM. Las garantías de seguridad de Plasma no cubrirían a todos los usuarios, ya que las razones fundamentales detrás de la imposibilidad de extender los juegos de salida al estilo de Plasma a muchos tipos de aplicaciones complejas aún permanecen. Sin embargo, un porcentaje muy elevado de los activos podría mantenerse seguro en la práctica.

Esta publicación describe cómo las ideas de Plasma se pueden extender para hacer tal cosa.

Descripción general: cómo funciona Plasma

La versión más sencilla de entender de Plasma es Plasma Cash. Plasma Cash funciona tratando cada moneda individual como un NFT separado y rastreando un historial separado para cada moneda. Una cadena de plasma tiene un operador, que es responsable de hacer y publicar regularmente bloques. Las transacciones en cada bloque se almacenan como un árbol de Merkle disperso: si una transacción transfiere la propiedad de la moneda k, aparece en la posición k del árbol. Cuando el operador de la cadena Plasma crea un nuevo bloque, publica la raíz del árbol de Merkle a encadenar, y envía directamente a cada usuario las ramas de Merkle correspondientes a las monedas que posee ese usuario.

Supongamos que estos son los tres últimos árboles de transacciones de una cadena de Plasma Cash. Entonces, asumiendo que todos los árboles anteriores son válidos, sabemos que Eva posee actualmente la moneda 1, David posee la moneda 4 y Jorge posee la moneda 6.

El principal riesgo en cualquier sistema de plasma es que el operador se comporte mal. Esto puede suceder de dos maneras:

  1. Publicar un bloque no válido (por ejemplo, el operador incluye una transacción que envía la moneda 1 de Fred a Hermione, incluso si Fred no posee la moneda en ese momento)
  2. Publicar un bloque no disponible (por ejemplo, el operador no envía a Bob su rama de Merkle para uno de los bloques, lo que le impide demostrar a otra persona que su moneda sigue siendo válida y no se ha gastado)

Si el operador se comporta mal de una manera que es relevante para los activos de un usuario, el usuario tiene la responsabilidad de salir inmediatamente (específicamente, dentro de los 7 días). Cuando un usuario ("el exiter") sale, proporciona una sucursal de Merkle que demuestra la inclusión de la transacción que transfirió esa moneda del propietario anterior a él. Esto inicia un período de desafío de 7 días, durante el cual otros pueden impugnar esa salida proporcionando una prueba de Merkle de una de estas tres cosas:

  1. No es el último propietario: una transacción posterior firmada por el saliente que transfiere la moneda del saliente a otra persona.
  2. Doble gasto: una transacción que transfirió la moneda del propietario anterior a otra persona, que se incluyó antes de la transacción que transfirió la moneda al saliente
  3. Historial no válido: una transacción que transfirió las monedas antes (en los últimos 7 días) que no tiene un gasto correspondiente. El saliente puede responder proporcionando el gasto correspondiente; Si no lo hacen, se produce un error en la salida.

Con estas reglas, cualquiera que posea la moneda k necesita ver todas las ramas de Merkle de la posición k en todos los árboles históricos durante la última semana para asegurarse de que realmente posee la moneda k y puede salir de ella. Necesitan almacenar todas las sucursales que contienen transferencias del activo, para que puedan responder a los desafíos y salir de manera segura con su moneda.

Generalización a tokens fungibles

El diseño anterior funciona para NFT. Sin embargo, mucho más comunes que los NFT son los tokens fungibles, como ETH y USDC. Una forma de aplicar Plasma Cash a los tokens fungibles es simplemente hacer que cada pequeña denominación de una moneda (p. ej. 0.01 ETH) un NFT separado. Desafortunadamente, los costos de gas de salir serían demasiado altos si hacemos esto.

Una solución es optimizar tratando muchas monedas adyacentes como una sola unidad, que se puede transferir o salir de todas a la vez. Hay dos formas de hacerlo:

  1. Use Plasma Cash casi tal cual, pero use algoritmos sofisticados para calcular el árbol de Merkle de una gran cantidad de objetos muy rápidamente si muchos objetos adyacentes son iguales. Sorprendentemente, esto no es tan difícil de hacer; Puedes ver una implementación de Python aquí.
  2. Utiliza Plasma Cashflow, que simplemente representa muchas monedas adyacentes como un solo objeto.

Sin embargo, ambos enfoques se topan con el problema de la fragmentación: si recibes 0,001 ETH cada uno de cientos de personas que te compran cafés, vas a tener 0,001 ETH en muchos lugares del árbol, por lo que salir de ese ETH aún requeriría presentar muchas salidas separadas, lo que hace que las tarifas de gas sean prohibitivas. Se han desarrollado protocolos de desfragmentación, pero son difíciles de implementar.

Alternativamente, podemos rediseñar el sistema para tener en cuenta un modelo más tradicional de "salida de transacción no gastada" (UTXO). Cuando sales de una moneda, tendrías que proporcionar la última semana de historia de esas monedas, y cualquiera podría impugnar tu salida demostrando que esas monedas históricas ya se habían salido.

Un retiro del UTXO de 0.2 ETH en la parte inferior derecha podría cancelarse mostrando un retiro de cualquiera de los UTXO en su historial, que se muestra en verde. Tenga en cuenta en particular que los UTXO del centro a la izquierda y de la parte inferior izquierda son antepasados, pero el UTXO de la parte superior izquierda no lo es. Este enfoque es similar a las ideas de coloración basadas en el orden de los protocolos de monedas de colores alrededor de 2013.

Existe una gran variedad de técnicas para hacerlo. En todos los casos, el objetivo es rastrear alguna concepción de lo que es "la misma moneda" en diferentes momentos de la historia, con el fin de evitar que "la misma moneda" sea retirada dos veces.

Desafíos de la generalización a EVM

Desafortunadamente, generalizar más allá de los pagos a la EVM es mucho más difícil. Un desafío clave es que muchos objetos de estado en la EVM no tienen un "propietario" claro. La seguridad de Plasma depende de que cada objeto tenga un propietario, que tiene la responsabilidad de vigilar y asegurarse de que los datos de la cadena estén disponibles, y salir de ese objeto si algo sale mal. Sin embargo, muchas aplicaciones de Ethereum no funcionan de esta manera. Los pools de liquidez de Uniswap, por ejemplo, no tienen un único propietario.

Otro desafío es que la EVM no intenta limitar las dependencias. El ETH mantenido en la cuenta A en el bloque N podría provenir de cualquier lugar del bloque N-1. Para salir de un estado consistente, una cadena de EVM Plasma necesitaría tener un juego de salida en el que, en el caso extremo, alguien que desee salir usando información del bloque N podría tener que pagar las tarifas para publicar todo el estado del bloque N en la cadena: un costo de gas de muchos millones de dólares. Los esquemas de Plasma basados en UTXO no tienen este problema: cada usuario puede salir de sus activos del bloque que sea el bloque más reciente para el que tenga los datos.

Un tercer desafío es que las dependencias ilimitadas en la EVM hacen que sea mucho más difícil tener incentivos alineados para demostrar la validez. La validez de cualquier estado depende de todo lo demás, por lo que probar cualquier cosa requiere probarlo todo. Por lo general, la resolución de fallos en una situación de este tipo no puede ser compatible con los incentivos debido al problema de la disponibilidad de datos. Un problema particularmente molesto es que perdemos la garantía, presente en los sistemas basados en UTXO, de que el estado de un objeto no puede cambiar sin el consentimiento de su propietario. Esta garantía es increíblemente útil, ya que significa que el propietario siempre está al tanto del último estado demostrable de sus activos y simplifica los juegos de salida. Sin él, crear juegos de salida se vuelve mucho más difícil.

Cómo las pruebas de validez pueden aliviar muchos de estos problemas

Lo más básico que pueden hacer las pruebas de validez para mejorar los diseños de las cadenas de plasma es demostrar la validez de cada bloque de plasma en la cadena. Esto simplifica enormemente el espacio de diseño: significa que el único ataque del operador del que tenemos que preocuparnos son los bloques no disponibles, y no los bloques no válidos. En Plasma Cash, por ejemplo, elimina la necesidad de preocuparse por los desafíos de la historia. Esto reduce el estado que un usuario necesita descargar, de una rama por bloque en la última semana, a una rama por recurso.

Además, los retiros del estado más reciente (en el caso común en el que el operador es honesto, todos los retiros serían del estado más reciente) no están sujetos a impugnaciones de no propietarios más recientes, por lo que en una cadena de Plasma de validez probada, dichos retiros no estarían sujetos a ningún desafío en absoluto. Esto significa que, en el caso normal, los retiros pueden ser instantáneos.

Extendiéndose a la EVM: gráficos UTXO paralelos

En el caso de EVM, las pruebas de validez también nos permiten hacer algo inteligente: se pueden usar para implementar un gráfico UTXO paralelo para tokens ETH y ERC20, y la equivalencia de prueba SNARK entre el gráfico UTXO y el estado EVM. Una vez que tenga eso, podría implementar un sistema de plasma "normal" sobre el gráfico UTXO.

Esto nos permite eludir muchas de las complejidades de la EVM. Por ejemplo, el hecho de que en un sistema basado en cuentas alguien pueda editar tu cuenta sin tu consentimiento (enviándole monedas y aumentando así su saldo) no importa, porque la construcción de Plasma no está sobre el estado EVM en sí, sino más bien sobre un estado UTXO que vive en paralelo a la EVM, donde las monedas que recibes serían objetos separados.

Extensión a la EVM: estado total de salida

Se han propuesto esquemas más simples para hacer una "EVM de plasma", por ejemplo. Plasma Free y antes de eso este post de 2019. En estos esquemas, cualquiera puede enviar un mensaje en la L1 para obligar al operador a incluir una transacción o poner a disposición una sucursal particular del estado. Si el operador no lo hace, la cadena comienza a revertir los bloques. La cadena deja de revertirse una vez que alguien publica una copia completa de todo el estado, o al menos de todos los datos que los usuarios han marcado como potencialmente faltantes. Hacer un retiro puede requerir la publicación de una recompensa, que pagaría la parte de ese usuario de los costos de gas de alguien que publica una cantidad tan grande de datos.

Esquemas como este tienen la debilidad de que no permiten retiros instantáneos en el caso normal, porque siempre existe la posibilidad de que la cadena necesite revertir el último estado.

Límites de los esquemas de plasma EVM

Esquemas como este son poderosos, pero NO son capaces de proporcionar garantías de seguridad completas a todos los usuarios. El caso en el que se desglosan más claramente es en situaciones en las que un objeto estatal particular no tiene un "propietario" económico claro.

Consideremos el caso de un CDP (posición de deuda colateralizada), un contrato inteligente en el que un usuario tiene monedas que están bloqueadas y solo pueden ser liberadas una vez que el usuario paga su deuda. Supongamos que el usuario tiene 1 ETH (~$2000 en el momento de escribir este artículo) bloqueado en un CDP con 1000 DAI de deuda. Ahora, la cadena Plasma deja de publicar bloques y el usuario se niega a salir. El usuario simplemente nunca podía salir. Ahora, el usuario tiene una opción gratuita: si el precio de ETH cae por debajo de los 1000 dólares, se aleja y se olvida del CDP, y si el precio de ETH se mantiene por encima, eventualmente lo reclama. En promedio, un usuario malintencionado de este tipo gana dinero haciendo esto.

Otro ejemplo es un sistema de privacidad, por ejemplo. Tornado Cash o Piscinas de Privacidad. Considere un sistema de privacidad con cinco depositantes:

Los ZK-SNARK en el sistema de privacidad mantienen oculto el vínculo entre el propietario de una moneda que entra en el sistema y el propietario de la moneda que sale.

Supongamos que solo se ha retirado orange y, en ese momento, el operador de la cadena Plasma deja de publicar datos. Supongamos también que usamos el enfoque gráfico UTXO con una regla de primero en entrar, primero en salir, de modo que cada moneda coincida con la moneda justo debajo de ella. Entonces, Orange podría retirar su moneda premezclada y postmezclada, y el sistema la percibiría como dos monedas separadas. Si el azul intenta retirar su moneda premezclada, el estado más reciente del naranja la reemplazaría; Mientras tanto, Blue no tendría la información para retirar su moneda post-mixta.

Esto se puede arreglar si permite que los otros cuatro depositantes retiren el contrato de privacidad en sí (que reemplazaría los depósitos) y luego retira las monedas en L1. Sin embargo, la implementación real de un mecanismo de este tipo requiere un esfuerzo adicional por parte de las personas que desarrollan el sistema de privacidad.

También hay otras formas de resolver la privacidad, por ejemplo. el enfoque Intmax , que consiste en poner unos pocos bytes en cadena al estilo rollup junto con un operador similar a Plasma que pasa información entre usuarios individuales.

Las posiciones LP de Uniswap tienen un problema similar: si cambiaste USDC por ETH en una posición de Uniswap, podrías intentar retirar tus USDC previos a la operación y tu ETH posterior a la operación. Si se confabula con el operador de la cadena Plasma, los proveedores de liquidez y otros usuarios no tendrían acceso al estado posterior a la negociación, por lo que no podrían retirar sus USDC posteriores a la negociación. Se requeriría una lógica especial para evitar situaciones como esta.

Conclusiones

En 2023, Plasma es un espacio de diseño infravalorado. Los resúmenes siguen siendo el estándar de oro y tienen propiedades de seguridad que no se pueden igualar. Esto es particularmente cierto desde la perspectiva de la experiencia del desarrollador: nada puede igualar la simplicidad de un desarrollador de aplicaciones que ni siquiera tiene que pensar en los gráficos de propiedad y los flujos de incentivos dentro de su aplicación.

Sin embargo, Plasma nos permite eludir por completo la cuestión de la disponibilidad de datos, lo que reduce en gran medida las tarifas de transacción. Plasma puede ser una mejora de seguridad significativa para cadenas que, de otro modo, serían válidas. El hecho de que los ZK-EVM finalmente estén dando sus frutos este año lo convierte en una excelente oportunidad para volver a explorar este espacio de diseño y crear construcciones aún más efectivas para simplificar la experiencia del desarrollador y proteger los fondos de los usuarios.

Renuncia:

  1. Este artículo es una reimpresión de [vitalik], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. 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 son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.

Salir de los juegos para las validaciones de EVM: el regreso de Plasma

Intermedio3/1/2024, 6:59:34 AM
Este artículo proporciona una explicación de Vitalik sobre el funcionamiento de Plasma, los retos a los que se enfrentan los NFT, los retos a los que se enfrenta la EVM y cómo la prueba de validez puede mitigar muchos de estos problemas.

Un agradecimiento especial a Karl Floersch, Georgios Konstantopoulos y Martin Koppelmann por sus comentarios, revisiones y discusiones.

Plasma es una clase de soluciones de escalado de blockchain que permiten que todos los datos y la computación, excepto los depósitos, retiros y raíces de Merkle, se mantengan fuera de la cadena. Esto abre la puerta a ganancias de escalabilidad muy grandes que no se ven obstaculizadas por la disponibilidad de datos en cadena. Plasma se inventó por primera vez en 2017 y vio muchas iteraciones en 2018, entre las que destacan Plasma Mínimo Viable, Plasma Cash, Plasma Cashflow y Plasma Prime. Desafortunadamente, desde entonces, Plasma ha sido reemplazado en gran medida por los rollups, por razones que tienen que ver principalmente con (i) los grandes costos de almacenamiento de datos del lado del cliente y (ii) las limitaciones fundamentales de Plasma que lo hacen <a href=" https://medium.com/@kelvinfichter /why-is-evm-on-plasma-hard-bf2d99c48df7"> difícil degeneralizar más alláde los pagos.

El advenimiento de las pruebas de validez (también conocidas como ZK-SNARK) nos da una razón para repensar esta decisión. El mayor desafío de hacer que Plasma funcione para los pagos, el almacenamiento de datos del lado del cliente, se puede abordar de manera eficiente con pruebas de validez. Además, las pruebas de validez proporcionan una amplia gama de herramientas que nos permiten crear una cadena similar al plasma que ejecuta una EVM. Las garantías de seguridad de Plasma no cubrirían a todos los usuarios, ya que las razones fundamentales detrás de la imposibilidad de extender los juegos de salida al estilo de Plasma a muchos tipos de aplicaciones complejas aún permanecen. Sin embargo, un porcentaje muy elevado de los activos podría mantenerse seguro en la práctica.

Esta publicación describe cómo las ideas de Plasma se pueden extender para hacer tal cosa.

Descripción general: cómo funciona Plasma

La versión más sencilla de entender de Plasma es Plasma Cash. Plasma Cash funciona tratando cada moneda individual como un NFT separado y rastreando un historial separado para cada moneda. Una cadena de plasma tiene un operador, que es responsable de hacer y publicar regularmente bloques. Las transacciones en cada bloque se almacenan como un árbol de Merkle disperso: si una transacción transfiere la propiedad de la moneda k, aparece en la posición k del árbol. Cuando el operador de la cadena Plasma crea un nuevo bloque, publica la raíz del árbol de Merkle a encadenar, y envía directamente a cada usuario las ramas de Merkle correspondientes a las monedas que posee ese usuario.

Supongamos que estos son los tres últimos árboles de transacciones de una cadena de Plasma Cash. Entonces, asumiendo que todos los árboles anteriores son válidos, sabemos que Eva posee actualmente la moneda 1, David posee la moneda 4 y Jorge posee la moneda 6.

El principal riesgo en cualquier sistema de plasma es que el operador se comporte mal. Esto puede suceder de dos maneras:

  1. Publicar un bloque no válido (por ejemplo, el operador incluye una transacción que envía la moneda 1 de Fred a Hermione, incluso si Fred no posee la moneda en ese momento)
  2. Publicar un bloque no disponible (por ejemplo, el operador no envía a Bob su rama de Merkle para uno de los bloques, lo que le impide demostrar a otra persona que su moneda sigue siendo válida y no se ha gastado)

Si el operador se comporta mal de una manera que es relevante para los activos de un usuario, el usuario tiene la responsabilidad de salir inmediatamente (específicamente, dentro de los 7 días). Cuando un usuario ("el exiter") sale, proporciona una sucursal de Merkle que demuestra la inclusión de la transacción que transfirió esa moneda del propietario anterior a él. Esto inicia un período de desafío de 7 días, durante el cual otros pueden impugnar esa salida proporcionando una prueba de Merkle de una de estas tres cosas:

  1. No es el último propietario: una transacción posterior firmada por el saliente que transfiere la moneda del saliente a otra persona.
  2. Doble gasto: una transacción que transfirió la moneda del propietario anterior a otra persona, que se incluyó antes de la transacción que transfirió la moneda al saliente
  3. Historial no válido: una transacción que transfirió las monedas antes (en los últimos 7 días) que no tiene un gasto correspondiente. El saliente puede responder proporcionando el gasto correspondiente; Si no lo hacen, se produce un error en la salida.

Con estas reglas, cualquiera que posea la moneda k necesita ver todas las ramas de Merkle de la posición k en todos los árboles históricos durante la última semana para asegurarse de que realmente posee la moneda k y puede salir de ella. Necesitan almacenar todas las sucursales que contienen transferencias del activo, para que puedan responder a los desafíos y salir de manera segura con su moneda.

Generalización a tokens fungibles

El diseño anterior funciona para NFT. Sin embargo, mucho más comunes que los NFT son los tokens fungibles, como ETH y USDC. Una forma de aplicar Plasma Cash a los tokens fungibles es simplemente hacer que cada pequeña denominación de una moneda (p. ej. 0.01 ETH) un NFT separado. Desafortunadamente, los costos de gas de salir serían demasiado altos si hacemos esto.

Una solución es optimizar tratando muchas monedas adyacentes como una sola unidad, que se puede transferir o salir de todas a la vez. Hay dos formas de hacerlo:

  1. Use Plasma Cash casi tal cual, pero use algoritmos sofisticados para calcular el árbol de Merkle de una gran cantidad de objetos muy rápidamente si muchos objetos adyacentes son iguales. Sorprendentemente, esto no es tan difícil de hacer; Puedes ver una implementación de Python aquí.
  2. Utiliza Plasma Cashflow, que simplemente representa muchas monedas adyacentes como un solo objeto.

Sin embargo, ambos enfoques se topan con el problema de la fragmentación: si recibes 0,001 ETH cada uno de cientos de personas que te compran cafés, vas a tener 0,001 ETH en muchos lugares del árbol, por lo que salir de ese ETH aún requeriría presentar muchas salidas separadas, lo que hace que las tarifas de gas sean prohibitivas. Se han desarrollado protocolos de desfragmentación, pero son difíciles de implementar.

Alternativamente, podemos rediseñar el sistema para tener en cuenta un modelo más tradicional de "salida de transacción no gastada" (UTXO). Cuando sales de una moneda, tendrías que proporcionar la última semana de historia de esas monedas, y cualquiera podría impugnar tu salida demostrando que esas monedas históricas ya se habían salido.

Un retiro del UTXO de 0.2 ETH en la parte inferior derecha podría cancelarse mostrando un retiro de cualquiera de los UTXO en su historial, que se muestra en verde. Tenga en cuenta en particular que los UTXO del centro a la izquierda y de la parte inferior izquierda son antepasados, pero el UTXO de la parte superior izquierda no lo es. Este enfoque es similar a las ideas de coloración basadas en el orden de los protocolos de monedas de colores alrededor de 2013.

Existe una gran variedad de técnicas para hacerlo. En todos los casos, el objetivo es rastrear alguna concepción de lo que es "la misma moneda" en diferentes momentos de la historia, con el fin de evitar que "la misma moneda" sea retirada dos veces.

Desafíos de la generalización a EVM

Desafortunadamente, generalizar más allá de los pagos a la EVM es mucho más difícil. Un desafío clave es que muchos objetos de estado en la EVM no tienen un "propietario" claro. La seguridad de Plasma depende de que cada objeto tenga un propietario, que tiene la responsabilidad de vigilar y asegurarse de que los datos de la cadena estén disponibles, y salir de ese objeto si algo sale mal. Sin embargo, muchas aplicaciones de Ethereum no funcionan de esta manera. Los pools de liquidez de Uniswap, por ejemplo, no tienen un único propietario.

Otro desafío es que la EVM no intenta limitar las dependencias. El ETH mantenido en la cuenta A en el bloque N podría provenir de cualquier lugar del bloque N-1. Para salir de un estado consistente, una cadena de EVM Plasma necesitaría tener un juego de salida en el que, en el caso extremo, alguien que desee salir usando información del bloque N podría tener que pagar las tarifas para publicar todo el estado del bloque N en la cadena: un costo de gas de muchos millones de dólares. Los esquemas de Plasma basados en UTXO no tienen este problema: cada usuario puede salir de sus activos del bloque que sea el bloque más reciente para el que tenga los datos.

Un tercer desafío es que las dependencias ilimitadas en la EVM hacen que sea mucho más difícil tener incentivos alineados para demostrar la validez. La validez de cualquier estado depende de todo lo demás, por lo que probar cualquier cosa requiere probarlo todo. Por lo general, la resolución de fallos en una situación de este tipo no puede ser compatible con los incentivos debido al problema de la disponibilidad de datos. Un problema particularmente molesto es que perdemos la garantía, presente en los sistemas basados en UTXO, de que el estado de un objeto no puede cambiar sin el consentimiento de su propietario. Esta garantía es increíblemente útil, ya que significa que el propietario siempre está al tanto del último estado demostrable de sus activos y simplifica los juegos de salida. Sin él, crear juegos de salida se vuelve mucho más difícil.

Cómo las pruebas de validez pueden aliviar muchos de estos problemas

Lo más básico que pueden hacer las pruebas de validez para mejorar los diseños de las cadenas de plasma es demostrar la validez de cada bloque de plasma en la cadena. Esto simplifica enormemente el espacio de diseño: significa que el único ataque del operador del que tenemos que preocuparnos son los bloques no disponibles, y no los bloques no válidos. En Plasma Cash, por ejemplo, elimina la necesidad de preocuparse por los desafíos de la historia. Esto reduce el estado que un usuario necesita descargar, de una rama por bloque en la última semana, a una rama por recurso.

Además, los retiros del estado más reciente (en el caso común en el que el operador es honesto, todos los retiros serían del estado más reciente) no están sujetos a impugnaciones de no propietarios más recientes, por lo que en una cadena de Plasma de validez probada, dichos retiros no estarían sujetos a ningún desafío en absoluto. Esto significa que, en el caso normal, los retiros pueden ser instantáneos.

Extendiéndose a la EVM: gráficos UTXO paralelos

En el caso de EVM, las pruebas de validez también nos permiten hacer algo inteligente: se pueden usar para implementar un gráfico UTXO paralelo para tokens ETH y ERC20, y la equivalencia de prueba SNARK entre el gráfico UTXO y el estado EVM. Una vez que tenga eso, podría implementar un sistema de plasma "normal" sobre el gráfico UTXO.

Esto nos permite eludir muchas de las complejidades de la EVM. Por ejemplo, el hecho de que en un sistema basado en cuentas alguien pueda editar tu cuenta sin tu consentimiento (enviándole monedas y aumentando así su saldo) no importa, porque la construcción de Plasma no está sobre el estado EVM en sí, sino más bien sobre un estado UTXO que vive en paralelo a la EVM, donde las monedas que recibes serían objetos separados.

Extensión a la EVM: estado total de salida

Se han propuesto esquemas más simples para hacer una "EVM de plasma", por ejemplo. Plasma Free y antes de eso este post de 2019. En estos esquemas, cualquiera puede enviar un mensaje en la L1 para obligar al operador a incluir una transacción o poner a disposición una sucursal particular del estado. Si el operador no lo hace, la cadena comienza a revertir los bloques. La cadena deja de revertirse una vez que alguien publica una copia completa de todo el estado, o al menos de todos los datos que los usuarios han marcado como potencialmente faltantes. Hacer un retiro puede requerir la publicación de una recompensa, que pagaría la parte de ese usuario de los costos de gas de alguien que publica una cantidad tan grande de datos.

Esquemas como este tienen la debilidad de que no permiten retiros instantáneos en el caso normal, porque siempre existe la posibilidad de que la cadena necesite revertir el último estado.

Límites de los esquemas de plasma EVM

Esquemas como este son poderosos, pero NO son capaces de proporcionar garantías de seguridad completas a todos los usuarios. El caso en el que se desglosan más claramente es en situaciones en las que un objeto estatal particular no tiene un "propietario" económico claro.

Consideremos el caso de un CDP (posición de deuda colateralizada), un contrato inteligente en el que un usuario tiene monedas que están bloqueadas y solo pueden ser liberadas una vez que el usuario paga su deuda. Supongamos que el usuario tiene 1 ETH (~$2000 en el momento de escribir este artículo) bloqueado en un CDP con 1000 DAI de deuda. Ahora, la cadena Plasma deja de publicar bloques y el usuario se niega a salir. El usuario simplemente nunca podía salir. Ahora, el usuario tiene una opción gratuita: si el precio de ETH cae por debajo de los 1000 dólares, se aleja y se olvida del CDP, y si el precio de ETH se mantiene por encima, eventualmente lo reclama. En promedio, un usuario malintencionado de este tipo gana dinero haciendo esto.

Otro ejemplo es un sistema de privacidad, por ejemplo. Tornado Cash o Piscinas de Privacidad. Considere un sistema de privacidad con cinco depositantes:

Los ZK-SNARK en el sistema de privacidad mantienen oculto el vínculo entre el propietario de una moneda que entra en el sistema y el propietario de la moneda que sale.

Supongamos que solo se ha retirado orange y, en ese momento, el operador de la cadena Plasma deja de publicar datos. Supongamos también que usamos el enfoque gráfico UTXO con una regla de primero en entrar, primero en salir, de modo que cada moneda coincida con la moneda justo debajo de ella. Entonces, Orange podría retirar su moneda premezclada y postmezclada, y el sistema la percibiría como dos monedas separadas. Si el azul intenta retirar su moneda premezclada, el estado más reciente del naranja la reemplazaría; Mientras tanto, Blue no tendría la información para retirar su moneda post-mixta.

Esto se puede arreglar si permite que los otros cuatro depositantes retiren el contrato de privacidad en sí (que reemplazaría los depósitos) y luego retira las monedas en L1. Sin embargo, la implementación real de un mecanismo de este tipo requiere un esfuerzo adicional por parte de las personas que desarrollan el sistema de privacidad.

También hay otras formas de resolver la privacidad, por ejemplo. el enfoque Intmax , que consiste en poner unos pocos bytes en cadena al estilo rollup junto con un operador similar a Plasma que pasa información entre usuarios individuales.

Las posiciones LP de Uniswap tienen un problema similar: si cambiaste USDC por ETH en una posición de Uniswap, podrías intentar retirar tus USDC previos a la operación y tu ETH posterior a la operación. Si se confabula con el operador de la cadena Plasma, los proveedores de liquidez y otros usuarios no tendrían acceso al estado posterior a la negociación, por lo que no podrían retirar sus USDC posteriores a la negociación. Se requeriría una lógica especial para evitar situaciones como esta.

Conclusiones

En 2023, Plasma es un espacio de diseño infravalorado. Los resúmenes siguen siendo el estándar de oro y tienen propiedades de seguridad que no se pueden igualar. Esto es particularmente cierto desde la perspectiva de la experiencia del desarrollador: nada puede igualar la simplicidad de un desarrollador de aplicaciones que ni siquiera tiene que pensar en los gráficos de propiedad y los flujos de incentivos dentro de su aplicación.

Sin embargo, Plasma nos permite eludir por completo la cuestión de la disponibilidad de datos, lo que reduce en gran medida las tarifas de transacción. Plasma puede ser una mejora de seguridad significativa para cadenas que, de otro modo, serían válidas. El hecho de que los ZK-EVM finalmente estén dando sus frutos este año lo convierte en una excelente oportunidad para volver a explorar este espacio de diseño y crear construcciones aún más efectivas para simplificar la experiencia del desarrollador y proteger los fondos de los usuarios.

Renuncia:

  1. Este artículo es una reimpresión de [vitalik], Todos los derechos de autor pertenecen al autor original [Vitalik Buterin]. 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 son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.
Empieza ahora
¡Registrarse y recibe un bono de
$100
!