Construyendo un mundo virtual: ¿Cómo usar la tecnología blockchain para controlar el tiempo de los "dioses digitales"?

Direccion original:

Traducido por: Justin @captainz

Como creadores de mundos virtuales, nuestro objetivo es crear entornos que sean divertidos y profundamente atractivos para los usuarios. Esto requiere que encontremos un equilibrio entre diseñar física digital que permita que surjan comportamientos complejos e inesperados y garantizar que la infraestructura existente pueda soportar estos comportamientos. Para hacer esto, debemos considerar tres dimensiones principales de la física digital: el tiempo, la forma de sus leyes y la medida en que se aplican esas leyes.

tiempo

Nos referimos al paso del tiempo en el mundo virtual como la aplicación iterativa de las leyes del mundo a sí mismo. Cada aplicación discreta es un "instante" en el flujo del tiempo en este mundo. Una forma de diseñar el tiempo en el mundo es hacerlo continuo con el tiempo externo. En un mundo virtual basado en blockchain, cada bloque corresponde a una cierta cantidad de momentos pasados en el mundo, sin importar qué transacciones contenga el bloque. Esto se conoce como tiempo sincrónico o el fenómeno del "tick". Este enfoque puede hacer que el mundo sea más interesante para los usuarios, ya que pueden ver los resultados de sus acciones en tiempo real. Además, da como resultado un tiempo más largo en el mundo y el mundo sigue actualizándose, lo que fomenta comportamientos interesantes.

Sin embargo, este enfoque también tiene sus desventajas. Los marcos de tiempo más grandes generalmente requieren más recursos informáticos, lo que puede superar rápidamente las capacidades de la cadena o el servidor. También puede ser difícil implementar este sistema en una cadena de bloques normal, ya que todos los cambios en la cadena deben iniciarse mediante transacciones iniciadas por usuarios externos.

Esta dificultad se vuelve evidente cuando imaginas algo aparentemente simple: un juego en cadena con personajes que no son jugadores (NPC). En la red principal Ethereum, puede definir una función de actualización que establece la posición de cada NPC en el mapa del juego y hacer que una cuenta externa lo llame periódicamente para actualizar su posición. Pero esto puede ser poco fiable, porque no se puede garantizar que la cuenta externa no será superada por la tarifa de gas en el bloque que debería llamar a la actualización. Por lo tanto, la estructura de tiempo en su juego se desviará (tome la función original CryptoKitties giveBirth() como ejemplo; a medida que aumenta la tarifa de gas en cadena, Axiom Zen en realidad tiene que aumentar la recompensa por llamar a la función giveBirth para garantizar que el nuevo NFT La transacción de nacimiento se llama 256 bloques después de que el usuario engendre a Kitty). Nos referimos a este método de usar cuentas externas como "tictac manual".

Los resúmenes personalizados nos brindan más flexibilidad para agregar la funcionalidad "tick" en la cadena, sin necesidad de cuentas externas, y el protocolo garantiza avances de tiempo sincronizados. Llamamos a este método "auto-tick". Los ticks automáticos se pueden implementar escribiendo un "contrato de ticks" que llama el propio protocolo en lugar de una cuenta externa.

Como ejemplo, @therealbytes desarrolló un tickchain de prueba de concepto basado en OP Stack que ejecuta una implementación de Game of Life de Conway que funciona automáticamente (puede encontrar una demostración en video aquí). Bytes utiliza una transacción de sistema modificada para invocar automáticamente el contrato de simulación de autómatas celulares tick-tick. Para probar completamente los límites de la cadena en sí, implementó el juego de dos maneras: una como un contrato inteligente de Solidity que se ejecuta en la cadena y la otra como una precompilación de la cadena en sí. La implementación de Solidity está maximizando la CPU después de alcanzar una cuadrícula de 70x70 con dos actualizaciones por bloque (1 bloque/seg, o alrededor de 10k celdas/seg), mientras que la cadena del motor precompilado personalizado está usando alrededor del 6 % Logrando la misma tasa para un 256x256 Grid con una CPU más alta (alrededor de 130k celdas/seg).

En la última frase del último párrafo, la palabra clave es "llegar al límite". Las cadenas tick-tick agregan una capa adicional de complejidad: cada bloque adicional requiere más estados para ser tocados por transacciones que simulan el juego. Eventualmente, los nodos de resumen estarán limitados por el cómputo sin procesar (CPU, E/S de disco, etc.). La única solución aquí es usar nodos de mayor capacidad.

Una alternativa al "tiempo sincrónico" es el "tiempo asincrónico". Bajo este esquema, el paso del tiempo en el mundo no necesariamente avanza como avanza el tiempo externo. En cambio, el tiempo normalmente avanza cuando ocurren ciertos eventos (generalmente acciones del usuario). Los juegos de mesa tradicionales que no involucran un temporizador entran en una categoría similar. Lograr un tiempo asíncrono en la cadena es más fácil porque ese es el modelo que las cadenas de bloques están diseñadas para soportar. Sin embargo, también sacrifica algunas características que podrían hacer que el mundo sea más interesante (como mover NPC automáticamente).

WildWood, una versión temprana de un juego de prueba de concepto de @notdavidhuang y cha0sg0d, revela este sacrificio. En este juego, dos jugadores deben defender su base de un asedio de NPC agresivos. En versiones anteriores del juego, el movimiento de los NPC solo se activaba cuando el jugador se movía, una implementación poco práctica del tiempo asíncrono. Después de agregar marcas, los NPC se movieron, pero persistió otro problema. La cadena marca cada segundo, lo que significa que si el jugador se mueve más de una vez por segundo, el juego debe transmitir la posición del jugador en el mapa con actualizaciones del resumen optimista. Sin embargo, sus compañeros de equipo no verán automáticamente a su cliente, lo que significa que habrá un retraso en las actualizaciones de posición de los jugadores. Para superar este problema, el equipo utilizó el servicio de retransmisión de MUD, una red de igual a igual para transmitir clientes locales a toda la cadena. Voila, se logra la transición del tiempo asincrónico al tiempo sincrónico.

Leyes de formas cerradas y abiertas

Los constructores de mundos también deben decidir si su mundo virtual sigue una representación de forma abierta o cerrada. Las expresiones de forma cerrada tienen un número fijo de operaciones. Sin embargo, el número de operaciones expresadas en forma abierta (o recursivamente) crece de acuerdo con las variables dadas. Bajo representaciones de forma abierta, el estado futuro del mundo solo se puede calcular aplicando repetidamente las leyes del mundo a estados conocidos. Los entornos gráficos complejos, como Dwarf Fortress, suelen entrar en esta categoría. Las representaciones de forma cerrada, por otro lado, permiten calcular cualquier estado futuro a partir de estados pasados y el tiempo transcurrido entre ellos (suponiendo que ninguna acción futura del usuario cambie el estado), como las tasas de extracción de recursos en Age of Empires II.

Los formularios abiertos pueden hacer que los mundos virtuales sean más interesantes porque, al igual que el mundo real, son impredecibles. Predecir el estado futuro del mundo requiere cada vez más tiempo y recursos informáticos (el Juego de la vida de Conway implementado en cadena es un buen ejemplo: no puede calcular estados futuros arbitrarios porque necesita ejecutar el juego a tiempo). Además, pueden surgir comportamientos macroscópicos inesperados a partir de interacciones microscópicas simples. En un mundo gobernado por una forma cerrada, estos comportamientos emergentes generalmente solo ocurren externamente, a través de las acciones de los usuarios (ellos mismos como en la forma abierta), y no dentro de la física del mundo en sí.

La compensación entre formas abiertas y cerradas implica un equilibrio similar al del tiempo. Las formas cerradas pueden hacer que el mundo sea potencialmente menos interesante, pero también lo hacen más eficiente desde el punto de vista computacional. La forma cerrada se puede utilizar con tiempo síncrono o asíncrono. Cuando se implementan en una cadena de bloques, tienen ventajas significativas sobre los formularios abiertos en lo que respecta a la sincronización de tiempo. Debido a que el costo es constante durante cualquier período de tiempo, el mundo puede diseñarse para actualizar solo el estado en cadena cuando un usuario envía una transacción, pero se establece en el estado después del tiempo transcurrido desde la última actualización.

Rango de tiempo y forma

Considere el enfoque estándar actual para la dinámica en cadena, un enfoque conocido como "actualizaciones perezosas". En una actualización diferida, el jugador inicia el inicio y el final de una acción, pero los tiempos intermedios se simulan en lugar de calcularse directamente. Por ejemplo, un jugador planta un manzano en el primer trozo y luego cosecha las manzanas en el décimo trozo. Se puede escribir una lógica de actualización perezosa para que los jugadores puedan cosechar una manzana por unidad de tiempo, un total de 9 manzanas. Esto está perfectamente bien para la lógica de actualización con funciones de formulario cerrado (como una manzana por bloque), pero falla si la lógica agrícola cambia según la entrada entre las acciones del jugador. Si en el bloque 5 una fuerte lluvia aumenta la tasa de crecimiento de las manzanas y en el bloque 7 una plaga de langostas casi destruye la cosecha, entonces en el bloque 10 no tiene ningún efecto sobre cuántas manzanas puede cosechar el jugador Computacional, a menos que realmente aplique todos los eventos que han ocurrido (no tendrá suficiente poder de cómputo para ponerse al día con el nuevo estado). Aún así, las actualizaciones perezosas son excelentes para cálculos económicos de ciertos mobs (como plantas con una tasa de crecimiento fija), pero aún no son suficientes para una caja de herramientas completa para un mundo dinámico.

En el mundo real, el tiempo está en todas partes y pasa todo a la vez, y el universo es potencialmente infinito (aunque con algunas complicaciones relativas a la relatividad). En un mundo virtual, sin embargo, este no es necesariamente el caso.

Primero, los mundos virtuales pueden estar claramente limitados. Las posibilidades de intriga generalmente aumentan con el tamaño: suceden más cosas en un mundo de 20 mil millones de galaxias que en un mundo de dos átomos, pero también lo hace el costo computacional. Ambas relaciones están estrechamente relacionadas con las dos compensaciones mencionadas anteriormente: el paso del tiempo y la forma física.

En segundo lugar, el tiempo no tiene que pasar por todas partes en el mundo virtual. El mundo se puede dividir en regiones discretas con diferentes lapsos de tiempo para reducir la carga computacional del mundo. Por ejemplo, se podrían usar reglas de física más complejas y costosas en áreas con actividad de usuarios, y reglas de física más simples en lugares donde no hay actividad. La desventaja de este enfoque es doble: puede hacer que el mundo parezca inconsistente y carente de integridad, lo que limita el espacio de diseño para las reglas del mundo y ejerce presión sobre los constructores del mundo para evitar confundir a los usuarios; limitando la propagación de la causalidad dentro del mundo, si las acciones de un área no puede tener consecuencias en áreas distantes, el espacio entre los dos está congelado en el tiempo. El tamaño del área donde se aplican las reglas de la física es una consideración de diseño importante que afectará los recursos que necesita un mundo y el nivel de diversión que puede alcanzar.

Para crear un mundo virtual interesante y atractivo, es necesario equilibrar cuidadosamente la eficiencia computacional y la diversión. Esto incluye decidir qué tipo de tiempo usar (sincrónico o asincrónico) y evaluar la forma de las leyes de la física que gobiernan el mundo. El tamaño del área a la que se aplican las leyes de la física es otra decisión importante. Al tomar estas decisiones con cuidado, los constructores de mundos no solo pueden mantener la carga computacional del mundo interesante de manejar, sino que también pueden proporcionar a otros desarrolladores una base muy fértil para la innovación.