¿Cómo desarrollar juegos on-chain verificables con Zypher?

Desde que Dojo del ecosistema Starknet propuso el concepto de juegos on-chain demostrables, muchos equipos han comenzado a explorar en este campo, como paima usando compresión de estado NFT, redux usando árbol de Merkle e inscripciones de estado, y así sucesivamente. Zypher Network (@Zypher_Network) también ha lanzado una serie de kits de desarrollo basados en la tecnología zk-SNARKs para ayudar a que los juegos on-chain sean verificables.

¿Qué es un juego on-chain verificable

Ahora sabemos que la combinación de la industria del juego y la tecnología de cadena de bloques tomará el modo GameFi de activos on-chain, o el modo de juego on-chain de estado on-chain. La definición general de un juego on-chain es esta: toda la lógica del juego, el estado (activos y otros) están en la on-chain, implementados a través de contratos inteligentes.

Como plataforma de contratos inteligentes, Ethereum es naturalmente una máquina de estado distribuida que puede hacer cálculos on-chain y verificación de estado un poco más simples. Así que todos intentaron escribir la lógica del juego en los contratos inteligentes, de modo que el juego se convirtió en un juego de descentralización sin un backend de servidor, y trajo un mayor grado de componibilidad en términos de reglas de juego. Sin embargo, también surge el problema: el poder de cómputo de Ethereum Mainnet es demasiado débil y el costo de uso es muy alto, incluso si considera usar cadenas de capa 2 de alto rendimiento u otras cadenas públicas, no puede satisfacer las necesidades de on-chain juegos

Inspirado en el rollup de capa 2, dado que las operaciones de transferencia a gran escala se pueden verificar off-chain la computación on-chain on-chain ¿por qué no manejar la ejecución de la lógica del juego de la misma manera? Aunque la lógica del juego se calcula off-chain, cada paso de la operación se puede verificar en la on-chain, lo que también garantiza la descentralización y la falta de confianza del juego, que es de donde proviene la palabra “verificable”, e incluso podemos simplemente analogizar: el TX en el rollup de capa 2 es una transacción de transferencia ordinaria, y el TX en el juego on-chain verificable es la transacción on-chain del juego.

Dependiendo del método de verificación on-chain, los rollups se dividen en OP-rollups y ZK-rollups. Del mismo modo, los juegos on-chain verificables que utilizan zk-SNARKs tienen ventajas sobresalientes en términos de finalidad y rendimiento de la verificación de estado, razón por la cual Dojo y Zypher Network eligieron ZKP para desarrollar juegos on-chain verificables.

Kit para desarrolladores de Zypher Network

El kit de desarrollo de Zypher Network consta de 3 partes, a saber, AW Engine, Secret Engine y Zytron kit.

1. AW Engine: Aprovecha las capacidades de compresión de información de ZKP para proporcionar escalabilidad. Un marco modular que permite que el juego sea verticalmente súper escalable. Programable a través de circuito o zkVM. Su SDK z4 puede soporte eventos de anhelo en el juego en tiempo real (jugador contra jugador).

2. Motor secreto: La capacidad de ocultar información de ZKP se utiliza para proporcionar juegos de información asimétrica. Un kit de desarrollo de software para zk-SNARKs como servicio que proporciona asimetría de información para juegos que requieren mecánicas de estrategia. ZK-SNARKs (ZKPs son capaces de implementar completamente el cálculo de privacidad y la aleatoriedad en la on-chain y pueden demostrar su imparcialidad.

3. Kit Zytron: Pila de capa 3. Una pila de cadena rollupL3 soberana que proporciona una implementación conveniente de la infraestructura del juego, incluida la optimización de la capa punto a punto, la fragmentación del servidor y más. Diseñado para juegos de anhelo masivo y construcción AW.

AW Engine, un framework modular para zk-SNARKs

AW Engine es responsable de la construcción del circuito ZKP, la generación de pruebas y la verificación de pruebas, por lo que está en el corazón de la suite. Consta de las siguientes secciones:

1. Gadgets (gadgets): admite varios gadgets utilizados en el desarrollo de circuitos de juegos, incluidos hashes básicos, ecc, máscaras, barajado, etc.
2. Circuitos específicos de la aplicación: use plonk específico de la aplicación como esquema básico para las pruebas de zk y escriba circuitos de juego específicos a través de varios dispositivos proporcionados por el SDK. Admite la compilación de circuitos directamente en wasm y puede ejecutarlos en un navegador o aplicación. Al mismo tiempo, también proporciona la capacidad de operar en diferentes máquinas virtuales (EVM / WASM / … Estos contratos pueden ejecutarse en diferentes sistemas de cadena de bloques para lograr la generación de pruebas off-chain y la verificación on-chain.
3. Validadores en cadena: wasm optimizado para probadores y validadores, así como soporte para validadores de solidez comunes para todas las cadenas EVM y validadores Move-lang para cadenas basadas en Move.
4. Motor PVP de anhelo Z4: Z4 es un sistema para juegos de anhelo en tiempo real. Escala las capacidades de procesamiento de eventos de anhelo mediante la externalización de eventos de jugador contra jugador (PvP) a nodos zk-rollup dedicados.

El diagrama anterior muestra el principio de funcionamiento y la arquitectura de AW Engine. Este motor de juego se divide en varias partes principales, y explicaré la función de cada sección paso a paso:

1. Zypher Plonk / Bulletproofs / Groth16 / STARKs: Todos estos son diferentes esquemas zk-SNARKs. Esto demuestra que el motor del juego admite los tipos más largos de esquemas ZKP, lo que permite a los desarrolladores de juegos elegir el sistema de prueba adecuado según sus necesidades.

2. VM/DSL general: se refiere a una máquina virtual de propósito general o lenguaje específico de dominio (DSL) utilizado para escribir y ejecutar la lógica del juego. Zypher Network ha anunciado oficialmente una asociación estratégica con Risc Zero, que se espera que integre la zkVM genérica de su familia.

3. Gadgets y circuitos Zypher: Estos gadgets y circuitos son los bloques de construcción básicos para construir ZKP. En los zk-SNARKs, los gadgets son funciones predefinidas o piezas de lógica, y los circuitos son los procesos computacionales más grandes que conectan estos gadgets.

4. Circuito de prueba de juego: El circuito de prueba de juego es una versión zk-SNARKs de toda la lógica del juego. Aquí, se crea un circuito que valida las reglas del juego sin revelar las acciones o estrategias específicas del jugador.

5. Prover API: La Prover API es una interfaz a través de la cual los desarrolladores generan pruebas. En el contexto del juego, esto significa demostrar que las acciones del jugador se llevaron a cabo de acuerdo con las reglas del juego.

6. Verificador en cadena API: El on-chain validadores API es otra interfaz para verificar las certificaciones proporcionadas anteriormente anteriormente. Esto se hace en la cadena de bloques para garantizar que cada paso del juego sea justo y transparente.

7. ZK Proof Market: Para los jugadores en dispositivos móviles, hay un mercado de computación de prueba de descentralización donde los jugadores pueden subcontratar Proof Computation; esto hace que el hardware de juegos on-chain sea agnóstico.

8. Juego: La parte del juego de la computación off-chain contiene la lógica real del juego y la interfaz de usuario que permite a los jugadores jugar.

9. Juego en cadena: Después de enviar la prueba al Cadena de bloques, el juego se convierte en un juego Descentralización y Sin confianza on-chain. Se puede comparar con DA Proof en la capa 2 para la operación on-chain.

En general, AW Engine aprovecha zk-SNARKs para garantizar la seguridad y la equidad del juego. Permite verificar la lógica del juego sin exponer ninguna información crítica, proporcionando una nueva forma de desarrollar y ejecutar juegos construidos en la cadena de bloques.

Por último, echemos un vistazo a todo el flujo de trabajo del motor desde la perspectiva de un desarrollador:

1. Etapa de desarrollo:

• Primero, los desarrolladores eligen el esquema zk-SNARKs apropiado (como Plonk, Bulletproofs, Groth16 o STARKs).

• A continuación, utilizan uno de estos escenarios para crear “artilugios y circuitos Zypher”, que son los componentes básicos de la lógica del juego.

• Estos bloques de construcción se combinan en un completo “Circuito a prueba de juegos”, que es un circuito de conocimiento cero que demuestra la validez del estado del juego sin revelar información específica.

2. Generación de pruebas (Prover API) :

• Cada acción o cambio de estado en el juego se convierte en una prueba en el backend a través de la “Prover API”, que es infalsificable y no revela ningún dato crítico del juego.

• Esta prueba significa que la acción del juego o el estado del juego del jugador está de acuerdo con las reglas del juego.

3. Autenticación on-chain (verificador en cadena API) :

• La prueba generada se envía a la cadena de bloques a través de la “API de verificación en cadena”.

• Este validador on-chain verificará la validez de la prueba de validación, confirmará la legitimidad de la acción o estado del juego y garantizará la equidad y corrección del juego.

El proceso anterior no incluye el sistema de batalla de anhelo Z4, de hecho, ZKP no solo puede “verificar” la lógica del juego, sino también “verificar” el “sistema de batalla de anhelo”.

La imagen de arriba es un diagrama de flujo de trabajo del motor Z4, y se puede ver que la forma en que el motor Z4 admite juegos de jugadores largo en tiempo real es crear salas sin estado para el emparejamiento de jugadores y el juego, que son Nodo soporte por zk-rollup, Nodo no guardan datos. Cuando la lógica del juego se ejecuta en el nodo, todas las operaciones se ordenan y resumen, y son confirmadas por zk-SNARKs. Una vez finalizado el juego, la prueba de la operación y la conclusión se carga en la on-chain para su verificación. Z4 Nodo puede ejecutar la lógica del juego directamente sin usar una máquina virtual, evitando las tarifas de transacción y gas. La máquina virtual (como WASM/EVM) también se puede usar en el nodo para ejecutar la lógica del juego si es necesario. Todo el proceso está diseñado para soporte volúmenes de toda la red de millones o incluso miles de millones por segundo para garantizar el rendimiento del juego en tiempo real y de alta simultaneidad.

Módulo de información asimétrica Secret Engine

La niebla de guerra es una mecánica que se encuentra comúnmente en los juegos, con ejemplos típicos que incluyen StarCraft y Warcraft 3. Este diseño oculta información cubriendo ciertas áreas del mapa del juego, que solo se revelan cuando el jugador explora esas áreas. Esta mecánica aumenta la imprevisibilidad del entorno de juego y es típica de los llamados juegos de información asimétrica. La mayoría de largo juegos MMO populares cuentan con mecánicas de juego de información asimétrica, que brindan a los jugadores una largo coro más para explorar y crear estrategias.

Sin embargo, en la tecnología de cadena de bloques, los datos suelen ser completamente abiertos y transparentes, lo que dificulta la implementación de mecanismos de información asimétrica. Sin embargo, al emplear zkSNARKs, una tecnología zk-SNARKs, los juegos de Dark Forest logran mantener su estado de privacidad, mientras que los jugadores deben enviar públicamente acciones válidas verificables. De esta manera, Dark Forest crea un entorno de juego con información incompleta sobre la cadena de bloques. Sin embargo, este complejo método de ocultación de información requiere una programación de circuitos ZK personalizada, por lo que no se puede implementar una ocultación de información extensa en juegos on-chain.

Secret Engine resuelve parcialmente este problema con WASM optimizado y contratos precompilados, e implementa un proceso de descentralización de alto rendimiento y bajo costo a través de Shuffle SDK. La mezcla de circuitos y protocolo garantizar la ejecución segura de cálculos de encriptación verificables, lo que garantiza que los elementos de la política permanezcan confidenciales en on-chain. Además del póker, el Monopoly y los juegos de cartas coleccionables, el SDK se puede aplicar a otros casos de uso de SLG que requieren confianza y aleatoriedad, como:

Engaño social: Un juego de engaño social que protege la identidad o estrategia secreta del jugador. Colocación secreta**:** Las acciones de colocación secretas en el juego, como ocultar unidades o ubicaciones de recursos, se pueden implementar de forma segura. Niebla de guerra:* es la niebla de guerra, que se puede usar para garantizar que ciertas partes del mapa se mantengan en secreto para ciertos jugadores hasta que se cumplan ciertas condiciones.

Hay dos SDK que se usan comúnmente:

zk-Shuffle-as-a-service:* Los jugadores se turnan para encriptar y barajar las cartas para producir una baraja de cartas “sellada” y ordenada al azar, que proporciona una solución que los generadores de números aleatorios tradicionales, como las funciones aleatorias verificables (VRF), no pueden proporcionar. zk-Matchmaking-as-a-service:* Los jugadores envían una “semilla de prueba” para generar un número aleatorio y emparejarlo on-chain, todo el proceso se puede probar a través de zkp.

En esta imagen se muestra el flujo de trabajo del SDK de Shuffle:

1. Zypher PlonK:

• Basic PlonK: Este es un esquema de prueba zk-SNARK de propósito general que permite generar pruebas para verificar la exactitud de cálculos complejos sin revelar información adicional.

• Selectores de barajado: Son lógicas o configuraciones específicas del proceso de barajado que permiten al sistema de prueba PlonK realizar correctamente el barajado de las cartas.

2. Circuito aleatorio:

• Chaum Pedersen: Este subcomponente se utiliza para garantizar la privacidad del proceso de barajado. Por lo general, se relaciona con firmas digitales o encriptación, donde la encriptación de cada tarjeta es segura.

• Revelar: Este paso consiste en revelar de forma segura la identidad de una tarjeta cuando sea necesario, sin revelar información sobre otras tarjetas.

• Permutación: Se refiere al proceso real de barajar las cartas, es decir, la reorganización de las cartas.

• Modelo de tarjeta: Esto define el modelo de datos de la tarjeta, que es esencial para crear la versión de encriptación de la tarjeta y luego verificar el barajado.

3. SDK de reproducción aleatoria:

• Prover SDK (Rust/WASM): Este kit de desarrollo de software permite a los desarrolladores de juegos generar zk-SNARKs para demostrar que el proceso de barajado es correcto sin revelar el orden real de las cartas.

• SDK de verificador en cadena (Solidity/WASM/Move): Este SDK se utiliza para crear on-chain validadores y verificar la corrección de las pruebas aleatorias.

La introducción anterior aún puede ser demasiado abstracta, usemos un Texas Hold’em on-chain como ejemplo para ilustrar el principio del SDK de Shuffle.

En el juego, necesitamos almacenar los resultados de la “pila barajada” en la on-chain. Esto sirve no solo como resultado del barajado actual, sino también como una entrada común para los “barajados” posteriores, como se demuestra en la operación Configurar pila. Inicialmente, configure la plataforma para almacenar la plataforma inicializada de forma predeterminada. Sin embargo, el almacenamiento on-chain es notoriamente caro, especialmente para grandes volúmenes de datos. Una baraja de 52 cartas consta de un total de 208 uint256 tipos de datos, lo que hace que los costos de almacenamiento sean una consideración importante.

La solución de Zypher es almacenar solo una parte de los datos en la on-chain después de barajar, específicamente, solo necesita almacenar 2n + 5 cartas, donde n es el número de jugadores. Dado que actualmente se admiten largos 6 jugadores, 17 cartas son largas como máximo. Esto significa que al final solo esas 17 tarjetas deben almacenarse en la on-chain. Pero como se mencionó anteriormente, otro propósito del almacenamiento on-chain es que estas tarjetas también servirán como una entrada común para barajados posteriores. Por lo tanto, si solo se almacenan 17 cartas, es imposible verificar la corrección del barajado.

Para resolver este problema, el circuito zk-shuffle de Zypher también genera el hash de la plataforma completa como una entrada común, que también se almacena on-chain. Al verificar zk-shuffle, el usuario carga la pila pre-shuffle como una entrada común, y el circuito calcula el hash de la tarjeta cargada por el usuario y lo compara con el hash almacenado en la on-chain. Finalmente, dado que solo una parte de los datos se mantiene on-chain, es posible que los usuarios deban adquirir las 52 tarjetas completas. Para ello, se pueden utilizar eventos de contrato. Los eventos son un método de comunicación de muy bajo costo que permite a los usuarios escuchar eventos para obtener datos completos del juego.

En resumen, el núcleo de todo el proceso es el uso de zk-SNARKs para garantizar la privacidad y corrección de la mezcla. De esta manera, las decisiones y estrategias de los jugadores permanecen privadas, incluso si todas las acciones se registran públicamente en la cadena de bloques.

Kit Zytron de pila Sovereign L3

El kit de Zytron es una pila de rollup soberano de capa 3 altamente personalizable que admite el motor de juego de Zypher como un contrato precompilado.

La infraestructura existente de Dapp, principalmente EVM, no tenía la vela con mecha larga para optimizar casos de uso altamente receptivos, como los juegos on-chain, y no proporcionaba la rentabilidad y escalabilidad requeridas. Los MMO y otros juegos de alto rendimiento requieren una infraestructura dedicada y personalizada con recursos informáticos eficientes y predecibles. La primera red alfa de Zytron, con 0 gases, 0.2S tiempo del bloque, contratos precompilados diseñados específicamente para juegos, se lanzará en un futuro próximo, con 10 juegos planeados como probadores pioneros.

El kit ofrece 4 componentes principales plug-and-play:

Sovereign Rollup: Lo más importante en el juego es la jugabilidad, que requiere la mayor disponibilidad (CAP) en un sistema distribuido, y todo el sistema se puede actualizar rápidamente e implementar automáticamente. Fragmentación del servidor: distribuye el mapa del mundo del juego en diferentes nodos para aumentar la capacidad de carga de un solo nodo. Al mismo tiempo, proporciona un conjunto de algoritmos de recuperación eficientes para moverse rápidamente entre diferentes nodos en el mapa global, cambiar entre diferentes servicios de nodos y sincronizar información. Compatibilidad de datos: Un componente crítico para la abstracción del almacenamiento, el protocolo integra bases de datos relacionales y de almacenamiento en caché más fáciles de usar para acelerar el procesamiento de datos del juego. Esta función aborda la necesidad de una gestión eficiente de los datos y un acceso rápido, que es esencial para mantener una experiencia de juego fluida. Redes personalizadas: Dadas las altas necesidades de red del juego, el marco optimiza la capa de red peer-to-peer (P2P) subyacente para escenarios de juego de soporte. Esto incluye optimizaciones para la mensajería dentro del grupo, utilizando técnicas NAT transversales y perforadoras para conexiones rápidas y eficientes. Además, la red ha diseñado una vela con mecha larga un protocolo UDP especial para el juego, que está diseñado para mantener la latencia por debajo de 10 milisegundos. Esto garantiza una transferencia de datos rápida y fiable, lo cual es esencial para las experiencias de juego en tiempo real.

Los rollups soberanos son un concepto más nuevo que agrega un mayor nivel de autonomía y flexibilidad a los rollups normales, lo que permite construir redes de cadena de bloques independientes con total autonomía sobre ellos. Esto significa que cada rollup soberano puede tener su propio mecanismo de consenso, máquina de estado y modelo de gobernanza, al tiempo que mantiene la compatibilidad con la cadena principal.

A partir del diagrama de fotogramas anterior, podemos entender las funciones de cada componente de la suite Zytron:

**1. Los componentes principales proporcionan la infraestructura de la cadena de juegos, lo que permite un alto grado de personalización y optimización. **

• Sovereign Rollup garantiza la jugabilidad y la alta disponibilidad del juego, soportando actualizaciones rápidas y despliegue automático del sistema.

• Server Fragmentación aumenta la capacidad de carga de un solo Nodo al distribuir el mundo del juego en largo Nodo.

• La compatibilidad de datos garantiza un procesamiento rápido de los datos del juego mediante la integración de un sistema de base de datos fácil de usar.

• La red personalizada optimiza la capa de red P2P subyacente para satisfacer las altas demandas de red del juego, incluida la mensajería optimizada entre grupos y la latencia reducida.

**2. Los componentes en cadena contienen las partes básicas que se ejecutan en la cadena on-chain para garantizar la corrección de la lógica del juego y la seguridad de los activos. **

• Los validadores on-chain garantizan que todas las transacciones y operaciones del juego sean válidas y legítimas.

• Los contratos inteligentes sirven como portador de codificación de las reglas y la lógica del juego, manejando la interacción entre los jugadores y el cambio de estado del juego.

**3. Los componentes del módulo proporcionan la implementación de características y servicios específicos del juego. **

• El sistema ZK proporciona soporte para la protección de la privacidad, como la computación y verificación que preservan la privacidad.

• El sistema de cuentas y el sistema de mensajería instantánea proporcionan funciones de gestión de usuarios y comunicación en tiempo real.

• Los sistemas de monitoreo se utilizan para monitorear las condiciones de la red y el estado del juego.

• Los sistemas de salas, los sistemas financieros y los sistemas de IA proporcionan gestión de salas en el juego, transacciones financieras y soporte de IA.

• El sistema de registro registra todas las operaciones y eventos para su análisis y depuración.

El diagrama anterior muestra el flujo de trabajo de la pila de kits de Zytron:

• Las transacciones se generan primero en la Capa 3 y se ordenan por secuenciador.
• El nodo Runner escucha los eventos de capa 1/2 y la salida del secuenciador, y se comunican entre sí para ejecutar transacciones y llegar a un consenso para implementar la funcionalidad de fragmentación de servicios.
• Los datos se envían a Celestia de forma periódica para garantizar la disponibilidad y seguridad de los datos.
• Los clientes interactúan con la capa 3 a través de la sincronización ligera y pueden invocar los servicios proporcionados por la capa 3.

Más interesante aún, los dos primeros conjuntos de motores, incluidos AW Engine y Secret Engine, se pueden integrar con el kit Zytron en una forma precompilada para proporcionar una infraestructura eficiente, receptiva y rica en funciones para juegos on-chain en una forma más minimalista. Los desarrolladores también pueden elegir los componentes apropiados de acuerdo con sus necesidades para crear un entorno de cadena que coincida con el diseño de su juego. Zypher no solo es compatible con el ecosistema ETH, sino que también está explorando activamente la posibilidad de on-chain juegos y L3 en el ecosistema BTC, Zypher y la red Layer2 B² de BTC anunciaron oficialmente que desplegarán on-chain capa 3 exclusiva del juego basada en B² Network y su DA Layer B² Hub, que será la primera capa 3 en el ecosistema BTC en soporte on-chain juegos. Zypher se ha convertido en el primer motor de desarrollo de juegos on-chain para dar soporte al ecosistema BTC.