El principal beneficio es reducir la cantidad de datos almacenados en Ethereum, lo que reduce el costo para que los usuarios realicen transacciones en L2.
**Escrito por: **OneTrueKirk
Compilado por: Yvonne, MarsBit
Publicación original de OneTrueKirk en ethresear.ch
Esta es la primera vez que publico sobre un tema aquí, así que pido disculpas si los ofendo de alguna manera. He estado pensando en esta idea (paquetes acumulativos sin estado) principalmente para paquetes acumulativos dedicados para nuestro protocolo de préstamo, pero espero que pueda ser aplicable en general, cualquier comentario es apreciado.
TLDR：
Solo se publica la raíz de estado, no los datos de llamada.
(Nota de MarsBit: Calldata es el valor de la parte de datos en la transacción del contrato y no se puede modificar).
detalle
¿Qué sucede si, en lugar de usar Ethereum como una capa de disponibilidad de datos, publica el estado completo como datos de llamadas y solo publica la raíz del estado en la red principal? El principal beneficio es reducir la cantidad de datos almacenados en Ethereum, lo que reduce el costo para que los usuarios realicen transacciones en L2. Incluso con EIP-4844, blobace no es gratis.
El principal riesgo es un ataque de retención de datos, en el que un proponente publica una raíz de estado válida pero retiene los datos completos de otros nodos acumulativos para monopolizar la producción futura de bloques o mantener los fondos como rehenes. Para evitar esto, los nodos honestos deben cuestionar cualquier actualización de estado para la cual ningún par pueda proporcionar datos. Las pruebas de fraude interactivas al estilo de Arbitrum se pueden usar para obligar a los proponentes a revelar el estado completo en la red principal, pero aun así hacen que el desafío falle si la raíz es válida, por lo que incluso en caso de falla, el costo del desafío es bajo.
(Nota de MarsBit: Ataque de retención de datos se refiere a un atacante que deliberadamente no devuelve todos los datos o devuelve datos incorrectos al acceder a datos protegidos, con el fin de lograr el propósito de engaño o destrucción.
Si el costo de fallar un desafío es bajo, los proponentes honestos podrían sentirse miserables al obligarlos a pagar por publicar todos los datos estatales en la red principal en defensa del desafío, incluso si propagaron los datos estatales punto a punto correctamente. El costo de iniciar un desafío debe ser proporcional al costo de defenderse para garantizar que los proponentes honestos no puedan ser atacados de esta manera.
En el peor de los casos, si un atacante puede gastar $ 1 para costarle $ 1 a un proponente honesto, puede obligar al proponente a darse por vencido y recuperar su bloqueo. Un nuevo proponente honesto puede ofertar y, a menos que el atacante pueda repetir el ataque a todos los posibles proponentes honestos, lo que incluye a todos los que tienen fondos, no puede causar un tiempo de inactividad permanente. Es posible agregar otra cláusula, donde el costo del desafío aumenta cuando ha pasado demasiado tiempo desde que se finalizó un bloque válido. De esta manera, es fácil desafiar a un proponente deshonesto, pero es imposible detener las transiciones de estado por mucho tiempo.
De manera más optimista, si los nodos distribuyen datos entre pares, pueden decidir sus propias soluciones de acceso y respaldo de datos, y los usuarios estarán mejor almacenando localmente los datos que necesitan para sus propias transiciones de estado. En el contexto de una aplicación en particular, pensé en codificar el estado de resumen de una manera completamente diferente a EVM para optimizar esto. Todo el estado asociado con una cuenta de usuario en particular se puede codificar en el mismo hash, por lo que los usuarios pueden verificar más fácilmente los cambios en su cuenta sin conocer el estado global (es decir, confirmar que recibió la cantidad de tokens sin preocuparse por su procedencia).
Resumir
Me encantaría escuchar sus pensamientos y agradecería los enlaces a trabajos relacionados. A diferencia del resumen optimista ordinario, en el resumen optimista es fácil determinar si los datos de llamada enviados coinciden con la raíz del estado de la red principal y si ambos son válidos, pero es imposible saber si una actualización es válida solo desde la raíz del estado, por lo que es necesario considerar cuidadosamente la economía de los períodos de desafío y duelo (es decir, comportamiento malicioso).
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Un vistazo rápido a las ventajas y los problemas potenciales del resumen sin estado
**Escrito por: **OneTrueKirk
Compilado por: Yvonne, MarsBit
Publicación original de OneTrueKirk en ethresear.ch
Esta es la primera vez que publico sobre un tema aquí, así que pido disculpas si los ofendo de alguna manera. He estado pensando en esta idea (paquetes acumulativos sin estado) principalmente para paquetes acumulativos dedicados para nuestro protocolo de préstamo, pero espero que pueda ser aplicable en general, cualquier comentario es apreciado.
TLDR：
Solo se publica la raíz de estado, no los datos de llamada.
(Nota de MarsBit: Calldata es el valor de la parte de datos en la transacción del contrato y no se puede modificar).
detalle
¿Qué sucede si, en lugar de usar Ethereum como una capa de disponibilidad de datos, publica el estado completo como datos de llamadas y solo publica la raíz del estado en la red principal? El principal beneficio es reducir la cantidad de datos almacenados en Ethereum, lo que reduce el costo para que los usuarios realicen transacciones en L2. Incluso con EIP-4844, blobace no es gratis.
El principal riesgo es un ataque de retención de datos, en el que un proponente publica una raíz de estado válida pero retiene los datos completos de otros nodos acumulativos para monopolizar la producción futura de bloques o mantener los fondos como rehenes. Para evitar esto, los nodos honestos deben cuestionar cualquier actualización de estado para la cual ningún par pueda proporcionar datos. Las pruebas de fraude interactivas al estilo de Arbitrum se pueden usar para obligar a los proponentes a revelar el estado completo en la red principal, pero aun así hacen que el desafío falle si la raíz es válida, por lo que incluso en caso de falla, el costo del desafío es bajo.
(Nota de MarsBit: Ataque de retención de datos se refiere a un atacante que deliberadamente no devuelve todos los datos o devuelve datos incorrectos al acceder a datos protegidos, con el fin de lograr el propósito de engaño o destrucción.
Si el costo de fallar un desafío es bajo, los proponentes honestos podrían sentirse miserables al obligarlos a pagar por publicar todos los datos estatales en la red principal en defensa del desafío, incluso si propagaron los datos estatales punto a punto correctamente. El costo de iniciar un desafío debe ser proporcional al costo de defenderse para garantizar que los proponentes honestos no puedan ser atacados de esta manera.
En el peor de los casos, si un atacante puede gastar $ 1 para costarle $ 1 a un proponente honesto, puede obligar al proponente a darse por vencido y recuperar su bloqueo. Un nuevo proponente honesto puede ofertar y, a menos que el atacante pueda repetir el ataque a todos los posibles proponentes honestos, lo que incluye a todos los que tienen fondos, no puede causar un tiempo de inactividad permanente. Es posible agregar otra cláusula, donde el costo del desafío aumenta cuando ha pasado demasiado tiempo desde que se finalizó un bloque válido. De esta manera, es fácil desafiar a un proponente deshonesto, pero es imposible detener las transiciones de estado por mucho tiempo.
De manera más optimista, si los nodos distribuyen datos entre pares, pueden decidir sus propias soluciones de acceso y respaldo de datos, y los usuarios estarán mejor almacenando localmente los datos que necesitan para sus propias transiciones de estado. En el contexto de una aplicación en particular, pensé en codificar el estado de resumen de una manera completamente diferente a EVM para optimizar esto. Todo el estado asociado con una cuenta de usuario en particular se puede codificar en el mismo hash, por lo que los usuarios pueden verificar más fácilmente los cambios en su cuenta sin conocer el estado global (es decir, confirmar que recibió la cantidad de tokens sin preocuparse por su procedencia).
Resumir
Me encantaría escuchar sus pensamientos y agradecería los enlaces a trabajos relacionados. A diferencia del resumen optimista ordinario, en el resumen optimista es fácil determinar si los datos de llamada enviados coinciden con la raíz del estado de la red principal y si ambos son válidos, pero es imposible saber si una actualización es válida solo desde la raíz del estado, por lo que es necesario considerar cuidadosamente la economía de los períodos de desafío y duelo (es decir, comportamiento malicioso).