- Tema
11k Popularidad
13k Popularidad
42k Popularidad
29k Popularidad
732 Popularidad
90k Popularidad
25k Popularidad
26k Popularidad
7k Popularidad
15k Popularidad
- Anclado
11k Popularidad
13k Popularidad
42k Popularidad
29k Popularidad
732 Popularidad
90k Popularidad
25k Popularidad
26k Popularidad
7k Popularidad
15k Popularidad
¿Cómo usar OPStack para construir el ciclo de reloj del juego de cadena completa?
Autor: Gametaverso
En general, los juegos se basan en bucles. Un bucle de juego es un proceso iterativo que normalmente consiste en procesar la entrada del usuario, actualizar el estado del juego y renderizar el mundo del juego. Este bucle continúa mientras se ejecuta el juego, normalmente de decenas a cientos de veces por segundo para mantener el flujo del mundo del juego.
Sin embargo, la arquitectura de blockchain está basada en push. Blockchain es una base de datos distribuida que comparte y almacena información a través de nodos en la red. Cuando un nodo genera una nueva transacción (como una transferencia, una llamada de contrato, etc.), la transacción se enviará a la red y otros nodos la verificarán y la agregarán a la cadena de bloques después de recibir la transacción. Este es un proceso pasivo, los nodos no buscarán activamente nuevas transacciones, sino que esperarán a que otros nodos en la red envíen nuevas transacciones. Por lo tanto, se dice que la arquitectura de blockchain está basada en push.
Por lo tanto, es muy importante implementar un sistema de ciclos con ciclos de reloj en el juego de cadena completa. Después de todo, en el llamado "mundo autónomo", todos esperamos que algunos NPC o entornos virtuales puedan evolucionar automáticamente con el tiempo, en lugar de evolucionar pasivamente siguiendo las entradas de transacciones enviadas a la cadena de bloques.
@therealbytes desarrolló una cadena de ticks de prueba de concepto (cadena con ciclos de reloj) basada en OP Stack, que ejecuta una implementación automática de tick-tick del Juego de la vida de Conway, veamos cómo lo implementó.
Para simplificar la traducción, literalmente traducimos tick por "tick", que significa "ciclo de reloj de ciclo".
Ticking-Optimism es una implementación de prueba de concepto de "Ticking Blockchain" basada en la arquitectura acumulativa Optimism Bedrock.
En la cadena de ticks, hay un contrato inteligente especial llamado "contrato de ticks", y el protocolo llamará automáticamente a cada bloque. Esto permite que otros contratos inteligentes se activen automáticamente en momentos o intervalos específicos sin requerir que los usuarios envíen transacciones.
Como alcanzar
La nueva arquitectura de resumen modular de Optimism, Optimism Bedrock, presenta un nuevo tipo de transacción llamado "Transacción de depósito". A diferencia de las transacciones regulares, las transacciones de depósito:
Bloques de la Capa 1.
No se requiere verificación de firma.
Compre gas L2 en L1, por lo que el gas L2 no es reembolsable.
En el Bedrock original, las transacciones de depósito se usaban para dos cosas:
Ejecutar transacciones enviadas directamente a L1.
Establecer propiedades L1 (número, marca de tiempo, hash, etc.) para contratos L2 implementados previamente en cada bloque.
En el último caso, las transacciones son creadas por nodos de resumen. No paga por el gas, y el gas utilizado no se deduce de la piscina de gas.
Ticking-Optimism modifica el nodo de resumen y también crea una "transacción de ticks" que funciona de la misma manera, pero en lugar de establecer la propiedad L1, llama a la función tick() en el contrato preimplementado para abordar 0x420000000000000000000000000000000000000A0. Este contrato puede llamar a otro contrato estableciendo su variable de destino.
Motivación
Para ilustrar el poder de las cadenas de ticks, imagine un juego en la cadena de bloques donde varios NPC (personajes que no son jugadores) se mueven por el mapa. Sin una cadena de ticks, tenemos dos enfoques de diseño principales:
Actualización perezosa. Del lado del cliente, los NPC parecen moverse continuamente, pero sus posiciones solo se actualizan en la cadena cuando los usuarios envían transacciones para interactuar con ellos. Luego, el contrato calcula la nueva ubicación del NPC en función de su última actualización en cadena y la cantidad de bloques que han pasado desde entonces.
Marcaje manual. Definimos una función de actualización que establece la posición de cada NPC en el mapa y hacemos que una cuenta externa lo llame periódicamente.
Con un tickchain, la solución es similar al tictac manual, pero el contrato de tictac llama a la función de actualización automáticamente en lugar de manualmente.
Las ventajas de utilizar el "auto-tick" de la cadena de ticks en lugar de los ticks manuales son:
Las actualizaciones están garantizadas por acuerdo.
La actualización se realizará antes de todas las transacciones en el bloque y no se puede hacer frente ya que es parte del propio protocolo.
Las transacciones de actualización no participan en el mercado regular de gas.
Sin embargo, los ticks automáticos requieren una cadena de bloques personalizada. Si la tasa de actualización es la misma, el tictac manual y automático requieren los mismos recursos informáticos en el nodo. Las actualizaciones perezosas, por otro lado, suelen ser más baratas porque las actualizaciones en cadena son más pequeñas y menos frecuentes.
Además, el costo computacional de las transacciones de ticks aumenta a medida que crece el estado que debe actualizarse. Esto ejerce una presión adicional sobre los desarrolladores para que diseñen sus aplicaciones de modo que los costos nunca excedan lo que la cadena puede soportar.
A pesar de estos enormes inconvenientes, las marcas automáticas son más adecuadas que las actualizaciones lentas para ciertos tipos de aplicaciones.
Los ticks permiten que los contratos inteligentes accedan, a un costo constante, a un estado dinámico que se actualiza mediante expresiones de formato abierto.
El estado (en el ejemplo anterior, la ubicación del NPC) siempre se puede leer en la cadena a un costo de gasolina constante y relativamente bajo. Pero el costo de calcular el estado actual aumentará con la cantidad de bloques desde la última actualización, y el costo del gas aumentará aún más.
Si estamos actualizando la posición de una entidad que se mueve a una velocidad constante, podemos calcular dónde debería estar en cualquier fragmento dado desde su última posición establecida y la cantidad de fragmentos desde la actualización. El costo de esta operación no crece con el número de bloques entre actualizaciones.
Por otro lado, si el estado que actualizamos es algo así como el Juego de la vida de Conway (o una simulación de tres gravedades), el costo de la actualización crece linealmente con el número de pasos desde la última actualización. Esto es un problema porque puede crecer más allá de lo que los usuarios están dispuestos a pagar o de lo que la cadena puede soportar.
Con actualizaciones diferidas, la lógica de actualización debe implementarse tanto en el contrato inteligente como en el cliente. Con el tictac, solo necesita implementarse en la cadena de bloques, y los clientes simplemente pueden reaccionar a los eventos en la cadena.
Las actualizaciones perezosas permiten a los desarrolladores distribuir su lógica de actualización en muchas funciones y contratos inteligentes, y cada función solo se activa cuando se ejecutan ciertas transacciones. Por el contrario, el enfoque tick-tick requiere solo una función de actualización que se garantiza que se active periódicamente. Este último facilita el mantenimiento de la coherencia y la integridad del estado.
Además, cada vez que se agrega un nuevo estado de actualización diferida (por ejemplo, un nuevo tipo de NPC), es posible que se deban modificar todas las funciones de actualización para tenerlo en cuenta. Esto hace que la base de código sea más compleja y propensa a problemas.
El costo de las actualizaciones perezosas a menudo varía ampliamente, y los usuarios pueden diseñar sus transacciones para que la mayor parte de la carga de las actualizaciones recaiga en otros. Con ticks, el costo de todas las operaciones es relativamente estable y no vulnerable a los ataques MEV.
Demostración del juego de la vida de Conway
Desarrollé una demostración de tickchain que ejecuta una versión interactiva del Juego de la vida de Conway. La cadena se ha modificado para incluir lógica de autómatas celulares en el motor de ejecución, lo que la hace más eficiente y permite un tablero de juego más grande que el que podría implementarse como código de bytes de contrato inteligente.
El código fuente de la demostración:
Vídeo de demostración: