El equipo de Lattice anunció recientemente Redstone : su nuevo L2 construido utilizando su nueva contribución a OP Stack (la pila que impulsa Optimism L2).

Por lo tanto, la pregunta que todos se hacen es: "¿Deberían construirse juegos en cadena en esta L2 y cómo se compara con las alternativas?". Muchos se han puesto en contacto con nuestro equipo de Paima Studios para pedir nuestra opinión, dado que somos uno de los principales creadores de juegos en cadena con juegos en vivo en múltiples cadenas, por lo que haremos todo lo posible para profundizar en los matices.

NOTA

En el momento de escribir este artículo, Redstone se ha anunciado recientemente. Web3 es un espacio que cambia muy rápidamente, por lo que le recomendamos que lea esta publicación de blog con la mente abierta a Redstone, ya que inevitablemente anunciarán más sobre su trabajo.

Para comprender Redstone y por qué existe, primero debe comprender cómo se compara con otras alternativas que se utilizan activamente en el mercado y sus ventajas y desventajas. En particular, en esta publicación de blog, nos centraremos en brindarle el modelo mental correcto para que pueda comprender lo que propone Redstone sin importar lo que anuncien a continuación.

Donde todo​empezó​

¿Entonces quieres crear un juego en cadena? Dado que Redstone es un Ethereum L2, asumiremos que ya se ha decidido a aprovechar Ethereum.

Entonces, ¿por qué no puedes implementar tu juego directamente en Ethereum? Quizás sepas que es porque cuesta demasiado (más de $1 por movimiento de juego al momento de escribir este artículo), pero ¿sabes por qué cuesta demasiado? Resulta que hay dos costos principales: el costo de ejecución y el costo de almacenamiento de datos, los cuales son prohibitivamente costosos para un juego. Sin embargo, al igual que las CPU son más caras que los discos duros, el costo de ejecución es significativamente mayor que los costos de almacenamiento. Entonces, ¿qué pasaría si pudiéramos encontrar una manera de convertir el costo de ejecución en costo de almacenamiento? Buenas noticias: los paquetes acumulativos hacen exactamente esto.

Rollups como​solución​de escalamiento

Los paquetes acumulativos vienen en muchas formas, cada uno de los cuales convierte los costos de ejecución en costos de almacenamiento a su manera:

1. Acumulaciones optimistas: ejecute el cálculo fuera de la cadena, luego almacene todos los datos necesarios para ejecutar la función (solo datos, sin ejecución) junto con el valor calculado localmente para el resultado. Realice la ejecución únicamente si alguien cree que el resultado que usted publicó es incorrecto (“a prueba de fraude”). \
   Ejemplos populares: Arbitrum, Optimismo.
2. Acumulaciones de ZK: ejecute el cálculo fuera de la cadena, luego almacene todos los datos necesarios para ejecutar la función (solo datos, sin ejecución) junto con la prueba ZK del resultado calculada localmente. \
   Ejemplos populares: ZK Sync, Starknet, Polygon zkEVM
3. Resumen soberano: ejecute el cálculo fuera de la cadena y luego almacene todos los datos necesarios para ejecutar la función (solo datos, sin ejecución). \
   Ejemplos populares: Rollkit, Paima Engine

Aprovechar estas soluciones reduce el costo de una transacción para su juego a aproximadamente $0,05 (consulte las tarifas de l2 para conocer los valores actualizados), lo que definitivamente es un gran paso en la dirección correcta.

Reducir el coste de​las L2​

Claramente, reducir los costos de estos L2 es clave para que los juegos tengan éxito. Aunque los paquetes acumulativos definitivamente se están volviendo más baratos (las computadoras mejoran, la tecnología ZK mejora, etc.), el costo principal no es ejecutar el cálculo fuera de la cadena, sino el costo de publicar los datos en la L1.

Para abordar esto, Ethereum introducirá una nueva forma de almacenar datos que es mucho más barata (llamada EIP4844) donde los datos solo se almacenan temporalmente (en la práctica, ~2 semanas para que sea suficiente tiempo para que se publique cualquier prueba de fraude y para que los datos sean replicados por nodos en todo el mundo).

Sin embargo, EIP4844 tiene algunas desventajas:

• Los datos son sólo temporales (necesitará encontrar otra solución de almacenamiento para mantenerlos alojados después)
• Los datos son limitados, con un límite de alrededor de 2 MiB por bloque (compartidos entre todos los paquetes acumulativos en Ethereum)

Como puede ver, aunque se están haciendo esfuerzos para reducir los costos, no serán suficientes para hacer viables los juegos en cadena en la L2, dado el continuo crecimiento del interés en el espacio blockchain (la velocidad de adopción es más rápida que la velocidad de la innovación técnica). )

Alternativa n.º 1: almacenar los datos en un servidor centralizado (o conjunto de servidores )

Una alternativa para mantener el costo bajo es simplemente almacenar los datos en un servidor centralizado cuya operación la gente confía en usted, y publicar solo un hash de los datos en la cadena. Una variante de esta idea es utilizar un grupo de máquinas operadas independientemente agregadas como un multisig. Este esquema se denomina "Comité de disponibilidad de datos" (DAC) y esto es lo que utilizan Arbitrum Nova, Arbitrum Orbit y Polygon CDK.

Estos esquemas son mucho más baratos ($0,001 / tx para Arbitrum Nova si se ignora el mercado de tarifas) a cambio de que la red esté más centralizada. El principal riesgo es que si el DAC deja de alojar los datos (por ejemplo: publican un hash y nunca comparten los datos de ese hash), la red se detiene.

Una nota especial sobre​Arbitrum​

Quizás tengas curiosidad por saber por qué Arbitrum aparece dos veces en la lista. Arbitrum ofrece 3 ofertas principales en este momento:

• Arbitrum One (la red principal de Arbitrum, que es un paquete completo con datos sobre Ethereum)
• Arbitrum Nova (un L2 que usa un DAC)
• Arbitrum Orbit (una pila para crear L3 para Arbitrum One)

Como puede ver, el problema con Nova es que no hay una buena manera de aprovechar DeFi para su juego (los usuarios tendrían que ir a (Nova -> ETH L1 -> One) y gastar mucho en gasolina solo para hacer un puente), mientras que la nueva pila Orbit te permite ir fácilmente (Orbit -> One). Además, dado que Orbit es una pila para crear L3, puedes usar un L3 existente como Xai Games que alimenta su propio DAC, o activar tu propio L3 (aunque si tienes un L3 específico del juego cuya única conexión a Ethereum publica ocasionalmente hashes, podría decirse que estarás mejor con web2.5)

Alternativa #2: almacenar los datos en otra​red​descentralizada

En lugar de esperar a que se implemente EIP4844 con ancho de banda limitado en la red principal, otros proyectos como Celestia, Avail y EigenDA han decidido implementar un concepto similar como una cadena separada (llamada capa de Disponibilidad de Datos (“DA”)), y centrándose puramente En este caso de uso, también ofrecen límites de datos más altos que los que la red principal de Ethereum planea admitir. Estas plataformas no admiten contratos inteligentes y, en cambio, están destinadas a utilizarse únicamente como capa de datos para las L2.

En particular, es posible crear una pila OP con datos sobre Celestia, así como un Arbitrum Orbit con datos sobre Celestia también. Esto conlleva algunas compensaciones:

1. Confianza. Su paquete acumulativo ahora depende de la capa DA para mayor seguridad además de Ethereum (pero podría decirse que es mejor que un DAC)
2. Costo. Su paquete acumulativo ahora debe pagar a la red DA por su seguridad (que debe pagar en el token nativo de la capa DA)
3. Velocidad. Los tiempos de bloqueo de Celestia son de 15 segundos y los tiempos de bloqueo de Avail son de 20 segundos. Por ejemplo, los datos deben llegar a Celestia antes de que puedan conectarse a EVM con el contrato blobstream de Celestia. Sin embargo, tome este punto con cautela, ya que todos los L2 en general emulan tiempos de bloqueo más rápidos de los que Ethereum realmente puede proporcionar (dado que los tiempos de bloqueo de Ethereum son solo 15 segundos a pesar de que Arbitrum usa un tiempo de bloqueo más rápido que este).

Este tipo de configuración es utilizado notablemente por Mantle (OP Stack + EigenLayer DA) y Manta Pacific (OP Stack + Celestia). El costo de estos aún está por verse, pero el equipo de Celestia reclama aproximadamente $0,001, lo que significa que el costo de almacenamiento en una capa DA (en relación con el costo de ejecución de un mercado de tarifas en el lado de EVM) es mínimo.

Alternativa n.° 3: almacenar los datos en un DAC que pueda​cuestionarse​

Finalmente, podemos hablar de lo que ofrece Redstone. Si no le gustan las ventajas y desventajas de almacenar datos en una capa DA, pero no le gusta la centralización de un DAC, puede crear un DAC donde pueda castigar financieramente al comité si no pone los datos a disposición. .

Para ayudar a comprender lo que esto significa, repasemos cómo funciona el protocolo DAC:

Cómo escribir​datos​

1. Sequencer for Redstone recibe su transacción
2. El secuenciador envía los datos al DAC para ser almacenados.
3. DAC devuelve un reconocimiento de que los datos están almacenados
4. El secuenciador publica el hash de los datos en L1

Cómo leer​datos​

1. Sincronice una cadena de Ethereum en busca de hashes que se enviaron al contrato acumulativo
2. Consultar los datos del hash del DAC.
3. Calcule el estado de la L2 basándose en estos datos.

Entonces, ¿qué​cambia​Redstone?

Al leer datos, si los datos no están disponibles, puede cuestionar al DAC alegando que no los puso a disposición (es decir, los datos no se pueden descargar desde su servidor).

Para incentivar adecuadamente a todos a ser honestos, configuramos las siguientes reglas de reducción:

1. Si un retador es deshonesto (los datos realmente estaban disponibles), se lo elimina (de lo contrario, podría atacar financieramente la red desafiando cada bloque)
2. Si el DCA es deshonesto (los datos no están disponibles), se les reduce drásticamente.

Esto parece una solución sencilla, pero la dificultad está en determinar quién tiene la culpa si ocurre un problema. Piense en el siguiente escenario:

1. El secuenciador publica un hash sin compartir los datos reales
2. Alguien desafía al secuenciador.
3. El secuenciador, viendo el desafío, pone a disposición los datos.

Si usted es un observador externo que no estaba monitoreando la cadena en tiempo real, los datos parecen disponibles (si consulta el DAC después del hecho, obtiene los datos como se esperaba), por lo que parece que el retador estaba mintiendo a pesar de que no eran.

Si su solución a este problema es asumir que el secuenciador nunca servirá solo para un juego, entonces ¿por qué no utilizar un DAC estándar? Además, asumir que el secuenciador es honesto no encaja bien con el concepto de una "supercadena" de secuenciador compartido, lo que significa que los activos no pueden usar el secuenciador compartido para ser transferidos entre cadenas OP Stack (por lo que se encuentra con el mismo problema que Arbitrum Nova a menos que Redstone se implementa como L3)

La forma en que el equipo de Lattice planea manejar esto será el punto clave a tener en cuenta a medida que haya más documentación e información sobre la hoja de ruta disponible.

Alternativa #4: Usar​ZK​

Tenga en cuenta que el problema de que los datos no se comparten (ataques de retención de datos) que afecta a Redstone no es exclusivo de los paquetes acumulativos optimistas. Los ZK Rollups cuyos datos se almacenan fuera de la cadena (llamados "Validiums") sufren el mismo problema, razón por la cual la gente generalmente está más interesada en los rollups (que publican todos los datos en una cadena).

Por lo tanto, los paquetes acumulativos de ZK, en general, no te ayudarán a reducir el costo de datos de tu juego de forma segura. Definitivamente pueden ayudar a escalar su juego de muchas otras maneras (mover más computación a la máquina local del usuario, usar pruebas recursivas para agrupar muchas interacciones, ya sea en estilo rollup o estilo canal de estado, etc.), pero ese es un tema para un publicación futura.

¿Cómo puedo reducir aún más los costos de mi juego si el problema es Solidity ?

En toda esta publicación de blog hemos hablado sobre cómo manejar los costos de almacenamiento. Sin embargo, algunos juegos pueden tener una CPU limitada (incluso si se ejecutan en una cadena EVM centralizada que operan). Si es usted, es posible que le interese utilizar un paquete acumulativo de Sovereign que le permita escalar su juego más allá de los límites de EVM utilizando Paima Engine.

Paima Engine permite crear máquinas de estado específicas de aplicaciones en Javascript que puede implementar en cualquier cadena EVM de su elección (¡incluido Redstone!). Estos paquetes acumulativos soberanos pueden acceder a información EVM (incluidos los datos del motor MUD) y, por lo tanto, pueden actuar como una excelente manera de hacer que cualquier parte de su juego se ejecute mucho más rápido y más barato.

​Conclusión​

En conclusión, reducir el costo de los datos es el paso más crucial para reducir los costos de los juegos en cadena. Existen muchas soluciones diferentes con diferentes compensaciones hoy en día, y Redstone se presenta como más seguro que el DAC estándar, pero queda por ver si es significativamente más seguro y si la diferencia es lo suficientemente significativa como para ser una alternativa viable. a soluciones respaldadas por capa DA. Para proyectos que necesitan escalar la computación sobre datos, existen soluciones como Paima Engine para abordar el problema.

Como descargo de responsabilidad final, recuerde que los detalles de Redstone aún no se han anunciado en su totalidad. Esta publicación de blog debería brindarle el modelo mental adecuado para comprender sus anuncios futuros, así que mantengamos la mente abierta y veamos qué proponen en el futuro.

​Estudios​Paima

Paima Studios, fundado en abril de 2022, son los desarrolladores principales de Paima Engine: un motor Web3 creado con una novedosa tecnología de capa 2 que permite crear juegos en cadena, gamificación y mundos autónomos. Paima Engine es una forma fácil y segura de ingresar a Web3, ya que se puede usar con habilidades de Web2 y no expone a los usuarios ni a los desarrolladores a riesgos ni ataques comunes de Web3.

• Base de código de Paima Engine: https://github.com/PaimaStudios/paima-engine
• Documentación de Paima: https://docs.paimastudios.com/
• Plantilla de Paima: https://github.com/PaimaStudios/paima-game-templates
• Paquete Paima NPM: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

También puedes conocer más en nuestras redes sociales:

• Youtube: <a href="https://www.youtube.com/@paimastudios""> https://www.youtube.com/@paimastudios
• Discordia: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• Gorjeo: https://twitter.com/PaimaStudios

¿Quieres trabajar juntos? No dude en comunicarse con nosotros a través de nuestra página de contacto: https://paimastudios.com/contact/

Descargo de responsabilidad:

1. Este artículo está reimpreso de [blog.paimastudios]. Todos los derechos de autor pertenecen al autor original [paimastudios]. 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.