原标题: Cómo aprendí a dejar de preocuparme y a amar la fragmentación
Enlace de video:
Orador: Scott Sunarto (@smsunarto) en el Día de la Investigación
Edición y finalización del artículo: Justin Zhao (@hiCaptainZ)
Hola, soy Scott (@smsunarto), fundador de August Labs (@ArgusLabs_). Hoy, voy a hablar sobre un tema que no hemos tocado en mucho tiempo. Con los roll-ups convirtiéndose en la corriente principal de los tiempos, no hablamos tanto de la fragmentación de ejecución como de la fragmentación de datos. Entonces, revisemos este tema algo descuidado: fragmentación de ejecución.
Esta será una conversación fácil. Sé que has estado escuchando conceptos complejos todo el día, así que intentaré que esta discusión sea lo más práctica posible. Preparé un diseño de diapositiva adecuado para esta presentación.
Para aquellos que no me conocen, lo gracioso es que soy conocida en Twitter como una chica anime. También me perdí mi graduación universitaria solo para estar aquí, para consternación de mis padres. Actualmente, soy el fundador de Argus Labs. Nos vemos a nosotros mismos como una empresa de juegos, no como una empresa de infraestructura o criptomonedas. Una de mis mayores molestias es que todos en los juegos criptográficos quieren crear herramientas, pero nadie quiere crear contenido o aplicaciones. Necesitamos más aplicaciones que los usuarios puedan usar.
Previamente, co-creé Dark Forest (@darkforest_eth) con mis inteligentes amigos Brian Gu (@gubsheep) y Alan Luo (@alanluo_0). Brian ahora ejecuta 0xPARC (@0xPARC) y es mucho más inteligente que yo.
La discusión de hoy se centrará en la realización de fragmentación, pero en un contexto que la mayoría de las personas no están familiarizadas con la discusión sobre la realización de fragmentación. Por lo general, analizamos la fragmentación de ejecución en el contexto de la capa 1, como la fragmentación de Ethereum o la fragmentación cercana. Pero hoy, quiero cambiar un poco el contexto. Pensemos en cómo se vería la fragmentación en un entorno de resumen.
La pregunta básica aquí es por qué una empresa de juegos crearía su propio resumen y qué podemos aprender de World of Warcraft para diseñar los resumen. Además, exploraremos cómo el espacio de diseño para roll-ups va mucho más allá de las realidades actuales.
Para responder a estas preguntas, volvamos a 2020, cuando se concibió por primera vez la idea del Bosque Oscuro. Nos preguntamos, ¿qué pasaría si creáramos un juego en el que cada acción del juego fuera una transacción en cadena? La premisa era ridícula en ese entonces, y todavía lo es para mucha gente hoy. Pero era una hipótesis interesante, así que la construimos y nació Dark Forest.
Dark Forest es un juego MMORTS de exploración espacial de cadena completa basado completamente en Ethereum, impulsado por ZK-Snarks. En 2020, ZK no era tan popular como lo es hoy porque casi no había documentación. La única documentación disponible para Circom es Google Docs de Jordi Baylina (@jbaylina). A pesar de los desafíos, aprendimos mucho en el camino y Dark Forest es la encarnación de esos aprendizajes.
Dark Forest es un experimento más grande de lo que pensábamos. Tenemos más de 10.000 jugadores, billones de gasolina gastados, caos en el juego, gente apuñalando por la espalda en la cadena. Lo más fascinante de Dark Forest y los juegos en cadena es la naturaleza de las plataformas. Al tener un juego de cadena completa, abre la puerta a un espacio de diseño para comportamientos emergentes, lo que permite a las personas crear contratos inteligentes que interactúan con el juego, así como clientes y modos de juego alternativos, como Dark Forest Arena y GPU miners.
Sin embargo, un gran poder conlleva una gran responsabilidad. Cuando lanzamos Dark Forest en xDai, ahora conocido como Gnosis Chain, terminamos llenando todo el espacio de bloques de la cadena. Esto hace que la cadena sea básicamente inutilizable para cualquier otra cosa, incluidas DeFi, NFT o cualquier otra cosa xDAI.
¿Y ahora qué? ¿Hemos llegado a un callejón sin salida? ¿Los juegos de cadena completa nunca se harán realidad? ¿O vamos a volver a hacer juegos en los que solo hay pequeñas imágenes JPEG en la cadena y convencer a la gente de que el dinero crece en los árboles? La respuesta es, dejamos que el software haga las cosas. Muchos de nosotros tenemos una visión muy rígida de blockchain y roll-ups, como si no hubiera mucho margen de mejora. Pero no estoy de acuerdo. Podemos experimentar y encontrar nuevas posibilidades.
Nos hicimos una pregunta: si tuviéramos que diseñar una cadena de bloques desde cero para juegos y solo juegos, ¿cómo sería? Necesitamos un alto rendimiento, por lo que necesitamos escalar lecturas y escrituras. La mayoría de las cadenas de bloques están diseñadas para escribir mucho. Las transacciones por segundo (TPS) es una métrica de la que la gente se jacta, pero en realidad, las lecturas son igual de importantes. ¿Cómo sabes dónde está un jugador si no puedes leer desde un nodo de blockchain? Este es en realidad el primer cuello de botella que encontramos en la construcción de blockchain.
Dark Forest tiene un problema en el que los nodos completos se usan mucho y la E/S explota porque necesitamos leer datos del estado en cadena. Esto resultó en miles de dólares en costos de servidor, que el equipo de xDAI cubrió generosamente para nosotros. Sin embargo, esto no es ideal para el largo plazo. Necesitamos un alto rendimiento, no solo para las transacciones escritas por segundo, sino también para las lecturas, como la obtención de datos de la propia cadena de bloques.
También necesitamos una cadena de bloques escalable horizontalmente para evitar el problema del vecino ruidoso. No queremos que un juego popular de repente comience a bloquearse en la cadena de bloques, deteniendo todo el trabajo. También necesitamos flexibilidad y capacidad de personalización para que podamos modificar la máquina de estado para diseñarla para el juego. Esto incluye tener un bucle de juego, hacerlo autoejecutable, etc.
Por último, pero no menos importante, para aquellos que no están familiarizados con la arquitectura de los juegos en línea, esto puede ser un poco vago, necesitamos una alta tasa de ticks. Las garrapatas son la unidad atómica de tiempo en el mundo del juego. En el contexto de las cadenas de bloques, tenemos bloques como unidades atómicas de tiempo. En los juegos, tenemos garrapatas. Esto es casi similar cuando construyes un juego de cadena completa, donde la tasa de generación de ticks o bloques de tu blockchain es igual al tick del juego en sí.
Por lo tanto, lo que necesitamos es una cadena de bloques con alto rendimiento, escalabilidad horizontal, flexibilidad y personalización, y una alta tasa de ticks. Tal diseño puede satisfacer las necesidades de la cadena de bloques que diseñamos desde cero para el juego.
Si tiene una tasa de ticks más alta o más bloques por segundo, el juego se sentirá más receptivo. Por el contrario, si su tasa de ticks es baja, el juego se sentirá lento. Una cosa clave para recordar es que si los fragmentos se retrasan, experimentará un retraso notable en el juego. Esta es una mala experiencia. Si alguna vez has lidiado con jugadores enojados que le gritan a la computadora por perder un juego, esa es una situación absolutamente terrible.
Actualmente, nuestros rollups tienen un bloque por segundo, lo que equivale a un tick. Si queremos tener juegos más geniales, necesitamos tasas de ticks más altas. Por ejemplo, Minecraft, un simple juego de pixel art, tiene 26 tics por segundo. Todavía estamos muy lejos de construir un juego tan receptivo como Minecraft.
Una posible solución es implementar nuestro propio paquete acumulativo. Si bien parece solucionar el problema, en realidad no soluciona la causa raíz del problema. Por ejemplo, tendrá un mayor rendimiento de escritura, pero no al nivel que necesitan los juegos. Por supuesto, si tu juego tiene cien jugadores, esto será suficiente. Sin embargo, si desea crear un juego que requiera un mayor rendimiento, existen restricciones muy estrictas debido a la forma en que se realiza la E/S en la compilación actual.
En el lado de lectura, realmente no obtienes una ganancia de rendimiento. Todavía necesita confiar en los indexadores. Realmente no tienes escalabilidad horizontal. Si intenta iniciar un nuevo paquete acumulativo para escalar horizontalmente su juego, destruirá su ecosistema de contrato inteligente existente. Los mercados implementados por jugadores no funcionarán con otras cadenas que lance para escalar horizontalmente su juego. Esto plantea muchas preguntas.
Finalmente, la alta tasa de ticks y los bloques por segundo siguen siendo un desafío, aunque podemos presionarlo lo más que podamos, podemos obtener dos bloques por segundo, tal vez tres, pero esta es realmente la forma en que funcionan estas cadenas de bloques. más lejos, porque hay un montón de cosas como volver a ordenar que dependen en gran medida de los ciclos de cómputo.
Para responder a esta pregunta, nos remontamos a principios de la década de 2000 y finales de la década de 1990, cuando apenas surgían juegos en línea como los MMO. Tienen un concepto llamado fragmentación. Este no es un concepto nuevo, ha existido en el pasado. La palabra "fragmentación" que usamos en la arquitectura de la base de datos en realidad proviene de una referencia a Ultima Online. Fueron los primeros en usar la palabra "fragmento" para explicar sus diferentes servidores.
Entonces, ¿cómo funciona la fragmentación en los juegos? No es una solución única para todos. Es una herramienta en la caja de herramientas, y la forma en que la adaptes a tu juego variará de un caso a otro. Por ejemplo, la primera construcción de fragmentación es lo que me gusta llamar fragmentación basada en la ubicación. Un buen modelo mental es imaginar un sistema de coordenadas cartesianas dividido en cuatro cuadrantes, cada uno con su propia porción del juego. Cada vez que quieres atravesar un fragmento, envías una comunicación a otro fragmento diciendo "oye, quiero moverme allí" y eres teletransportado a tu fragmento, dejando a los jugadores delante de tu cuerpo. Al hacer esto, distribuye la carga de trabajo del servidor entre varias instancias físicas, en lugar de obligar a un servidor a realizar todos los cálculos para todo el mundo del juego. La segunda configuración es ahora más popular. Se llama fragmentación multiverso, donde tienes varias instancias de juego que se reflejan entre sí. Puede elegir el fragmento al que desea ir, y la carga se equilibra de forma predeterminada para que cada servidor no esté saturado.
Ahora, la pregunta clave es, ¿cómo traes este concepto al resumen? Por eso creamos World Engine. World Engine es nuestra infraestructura insignia, básicamente un clasificador de fragmentos obstinado diseñado para el inicio. El nuestro es diferente y se adapta mejor a nuestras necesidades que muchos de los diseños de clasificadores de fragmentos que hemos visto en las últimas discusiones. La dirección de nuestra optimización es: A, rendimiento, B, queremos asegurarnos de que no haya bloqueos que bloqueen el tiempo de ejecución para garantizar que la tasa de ticks y el tiempo de bloqueo sean lo más eficientes posible, por lo que es sincrónico de forma predeterminada, la forma diseñamos que el clasificador sea una clasificación parcial, en lugar de forzar un pedido total (cada transacción debe ocurrir después de la otra).
Los componentes clave aquí son que tenemos dos cosas principales. Tenemos fragmentación basada en EVM, que es como una cadena EVM pura, en la que los jugadores pueden implementar contratos inteligentes, combinarlos con juegos, crear mercados con impuestos, etc. Es como una cadena normal, ¿verdad? Algo así como un bloque por segundo o algo así, lo suficiente para que puedas hacer todos tus dispositivos y mercados típicos.
El ingrediente secreto aquí es que también usamos un fragmento de juego, que es esencialmente una mini cadena de bloques diseñada como un servidor de juegos de alto rendimiento. Tenemos una interfaz de implementación propia para que pueda personalizar este fragmento a su gusto. Puede construir sus propios fragmentos e inyectarlos en el fragmento base. Solo necesita implementar un conjunto de interfaces estándar, al igual que el Cosmos con el que está familiarizado, Cosmos tiene una interfaz ABC. Básicamente, puede juntar esto en una especificación similar, trayendo sus propios fragmentos a la pila de World Engine.
La clave aquí es que tenemos una alta tasa de verificación que actualmente no podemos lograr con la construcción de fragmentación actual. Aquí es donde quiero presentarles a Cardinal. Cardinal es la primera implementación de fragmentación de juegos de World Engine. Utiliza Entity-Component-System (ECS) con una arquitectura orientada a datos. Esto nos permite paralelizar el juego y aumentar el rendimiento de los cálculos del juego. Tiene una tasa de tictac configurable de hasta 20 tics por segundo. Para la gente de blockchain aquí, eso es 20 bloques por segundo.
También podemos geolocalizarlo para reducir la latencia. Por ejemplo, es posible que tenga un clasificador en los EE. UU. y luego los asiáticos tengan que esperar 300 milisegundos para que la transacción llegue al clasificador. Este es un gran problema en los juegos porque 300 ms es mucho tiempo. Si intentas jugar un juego FPS con un retraso de 200 ms, básicamente, estás muerto.
Otro punto clave que también es importante para nosotros es que es auto indexable. Ya no necesitamos indexadores externos. No necesitamos estos marcos para almacenar en caché el estado del juego. Esto también nos permite crear más juegos en tiempo real sin problemas de latencia, ya que el indexador todavía está tratando de ponerse al día con los bloques de clasificación.
También tenemos un sistema de complementos que permite a las personas paralelizar la validación ZK, etc. La mejor parte, al menos para mí, es que puedes escribir tu código en Go. Ya no es necesario usar Solidity para que tu juego funcione. Si alguna vez has intentado crear un juego de cadena de bloques con Solidity, ha sido una pesadilla.
Sin embargo, el punto clave de nuestra construcción de fragmentos es que puedes construir cualquier cosa como un fragmento. Son básicamente como un espacio de diseño infinito, como lo que puede ser un fragmento.
Suponiendo que no te gusta escribir el código de tu juego en Go, entonces puedes elegir otras formas. Sin embargo, estamos trabajando en un fragmento de juego de Solidity que le permitirá implementar juegos en Solidity de una manera que ofrezca posibilidades de codificación y retenga muchos de los beneficios de Cardinal. También puede crear un fragmento acuñado de NFT con un mempool único y una construcción de pedido, resolviendo el problema del vecino ruidoso de forma similar a la acuñación básica. Incluso puede crear un fragmento de identidad de juego y usar NFT para representar su identidad de juego, de modo que pueda realizar fácilmente transacciones de identidad de juego a través de NFT en lugar de compartir claves privadas.
Esta es una arquitectura de alto nivel y no entraré en demasiados detalles hoy debido a limitaciones de tiempo. Fundamentalmente, permitimos que los contratos inteligentes de EVM se combinen con fragmentos de juegos mediante el uso de selección y pase personalizados. Creamos un envoltorio alrededor de Geth para permitir la comunicación entre ellos, lo que abre mucho espacio de diseño en ambas direcciones. Estamos sincronizados de forma predeterminada y podemos interoperar sin problemas y de forma componible entre fragmentos sin bloqueos.
Nuestro clasificador compartido es diferente en el sentido de que no utiliza la construcción de secuencias compartidas que prioriza los paquetes atómicos ordenados globalmente, lo que requiere un mecanismo de bloqueo y causa problemas como el bloqueo del subproceso principal, lo que genera velocidades de marcación y tiempos de bloqueo inestables, y el resultado es un retraso en el juego. También impone límites en los tiempos de bloque por fragmento y requiere varias construcciones y criptoeconomía para evitar la denegación de servicio. Hay otro gran problema que no he visto mencionado en muchas construcciones de clasificadores de VCR: si tiene diferentes fragmentos que dependen unos de otros y se bloquean, ¿cómo lo resuelve? Con el diseño asíncrono, esto no es un problema, porque todos hacen lo que quieren hacer y luego lo dejan pasar.
De hecho, los haces atómicos y los roll-ups a través de los fragmentos no suelen ser necesarios. Para nuestro caso de uso, no necesitamos nada que requiera haces atómicos, ni creemos que debamos diseñar nuestros Roll-Ups en torno a la pureza del caso de uso. Esto también trae muchas otras características interesantes. Por ejemplo, cada fragmento de juego podría tener una capa DA separada para la cadena base. Por ejemplo, puede usar el fragmento base para enviar datos a Ethereum, y el fragmento del juego puede enviar datos a Celestia (similar a un comité de disponibilidad de datos). También puede reducir los requisitos de hardware para ejecutar un nodo completo, ya que puede ejecutar el nodo completo Geth del fragmento base por separado, sin ejecutar el nodo del fragmento del juego, lo que facilita la integración con cosas como Alchemy.
Para resumir, quiero ser honesto aquí, mucha gente espera que sus construcciones resuelvan todos sus problemas, pero nosotros no. Creemos que nuestra construcción funciona para nosotros, pero podría no funcionar para su caso de uso. No es realista suponer que nuestras construcciones funcionarán para todos. Para nosotros, se ajustaba a nuestras necesidades y ofrecía un alto rendimiento, escalabilidad horizontal, flexibilidad y altas tasas de ticks, pero no era una cura para el cáncer. Si necesita un protocolo DeFi que requiera componibilidad sincrónica, es posible que esta construcción no sea para usted.
En general, realmente creo en el concepto de una arquitectura blockchain centrada en el ser humano. Al diseñar en torno a roles de usuario y casos de uso específicos, puede hacer mejores concesiones, en lugar de tratar de resolver los problemas de todos. Ha llegado la era del renacimiento y todo el mundo puede diseñar sus propios Roll-Ups para satisfacer sus necesidades específicas, en lugar de depender de una solución general. Creo que deberíamos abrazar la Explosión Cámbrica. No construya roll-ups como la capa uno con talla única porque no está diseñado para resolver el mismo problema en absoluto. Personalmente, espero ver a más personas explorar más el espacio de diseño de Roll-Up para casos de uso. Por ejemplo, ¿cómo sería un Roll-Up diseñado específicamente para el intercambio de activos? ¿Estará basado en la intención? ¿Cómo sería un Roll-Up diseñado específicamente para CLOB (Libro de órdenes de límite central) en cadena? Toma, le entrego el micrófono a MJ. Gracias por su invitación.
Versión inglesa:
Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
¿Por qué Argus usa fragmentación para construir una infraestructura de juego de cadena completa?
原标题: Cómo aprendí a dejar de preocuparme y a amar la fragmentación
Enlace de video:
Orador: Scott Sunarto (@smsunarto) en el Día de la Investigación
Edición y finalización del artículo: Justin Zhao (@hiCaptainZ)
Hola, soy Scott (@smsunarto), fundador de August Labs (@ArgusLabs_). Hoy, voy a hablar sobre un tema que no hemos tocado en mucho tiempo. Con los roll-ups convirtiéndose en la corriente principal de los tiempos, no hablamos tanto de la fragmentación de ejecución como de la fragmentación de datos. Entonces, revisemos este tema algo descuidado: fragmentación de ejecución.
Esta será una conversación fácil. Sé que has estado escuchando conceptos complejos todo el día, así que intentaré que esta discusión sea lo más práctica posible. Preparé un diseño de diapositiva adecuado para esta presentación.
Para aquellos que no me conocen, lo gracioso es que soy conocida en Twitter como una chica anime. También me perdí mi graduación universitaria solo para estar aquí, para consternación de mis padres. Actualmente, soy el fundador de Argus Labs. Nos vemos a nosotros mismos como una empresa de juegos, no como una empresa de infraestructura o criptomonedas. Una de mis mayores molestias es que todos en los juegos criptográficos quieren crear herramientas, pero nadie quiere crear contenido o aplicaciones. Necesitamos más aplicaciones que los usuarios puedan usar.
Previamente, co-creé Dark Forest (@darkforest_eth) con mis inteligentes amigos Brian Gu (@gubsheep) y Alan Luo (@alanluo_0). Brian ahora ejecuta 0xPARC (@0xPARC) y es mucho más inteligente que yo.
La discusión de hoy se centrará en la realización de fragmentación, pero en un contexto que la mayoría de las personas no están familiarizadas con la discusión sobre la realización de fragmentación. Por lo general, analizamos la fragmentación de ejecución en el contexto de la capa 1, como la fragmentación de Ethereum o la fragmentación cercana. Pero hoy, quiero cambiar un poco el contexto. Pensemos en cómo se vería la fragmentación en un entorno de resumen.
La pregunta básica aquí es por qué una empresa de juegos crearía su propio resumen y qué podemos aprender de World of Warcraft para diseñar los resumen. Además, exploraremos cómo el espacio de diseño para roll-ups va mucho más allá de las realidades actuales.
Para responder a estas preguntas, volvamos a 2020, cuando se concibió por primera vez la idea del Bosque Oscuro. Nos preguntamos, ¿qué pasaría si creáramos un juego en el que cada acción del juego fuera una transacción en cadena? La premisa era ridícula en ese entonces, y todavía lo es para mucha gente hoy. Pero era una hipótesis interesante, así que la construimos y nació Dark Forest.
Dark Forest es un juego MMORTS de exploración espacial de cadena completa basado completamente en Ethereum, impulsado por ZK-Snarks. En 2020, ZK no era tan popular como lo es hoy porque casi no había documentación. La única documentación disponible para Circom es Google Docs de Jordi Baylina (@jbaylina). A pesar de los desafíos, aprendimos mucho en el camino y Dark Forest es la encarnación de esos aprendizajes.
Dark Forest es un experimento más grande de lo que pensábamos. Tenemos más de 10.000 jugadores, billones de gasolina gastados, caos en el juego, gente apuñalando por la espalda en la cadena. Lo más fascinante de Dark Forest y los juegos en cadena es la naturaleza de las plataformas. Al tener un juego de cadena completa, abre la puerta a un espacio de diseño para comportamientos emergentes, lo que permite a las personas crear contratos inteligentes que interactúan con el juego, así como clientes y modos de juego alternativos, como Dark Forest Arena y GPU miners.
Sin embargo, un gran poder conlleva una gran responsabilidad. Cuando lanzamos Dark Forest en xDai, ahora conocido como Gnosis Chain, terminamos llenando todo el espacio de bloques de la cadena. Esto hace que la cadena sea básicamente inutilizable para cualquier otra cosa, incluidas DeFi, NFT o cualquier otra cosa xDAI.
¿Y ahora qué? ¿Hemos llegado a un callejón sin salida? ¿Los juegos de cadena completa nunca se harán realidad? ¿O vamos a volver a hacer juegos en los que solo hay pequeñas imágenes JPEG en la cadena y convencer a la gente de que el dinero crece en los árboles? La respuesta es, dejamos que el software haga las cosas. Muchos de nosotros tenemos una visión muy rígida de blockchain y roll-ups, como si no hubiera mucho margen de mejora. Pero no estoy de acuerdo. Podemos experimentar y encontrar nuevas posibilidades.
Nos hicimos una pregunta: si tuviéramos que diseñar una cadena de bloques desde cero para juegos y solo juegos, ¿cómo sería? Necesitamos un alto rendimiento, por lo que necesitamos escalar lecturas y escrituras. La mayoría de las cadenas de bloques están diseñadas para escribir mucho. Las transacciones por segundo (TPS) es una métrica de la que la gente se jacta, pero en realidad, las lecturas son igual de importantes. ¿Cómo sabes dónde está un jugador si no puedes leer desde un nodo de blockchain? Este es en realidad el primer cuello de botella que encontramos en la construcción de blockchain.
Dark Forest tiene un problema en el que los nodos completos se usan mucho y la E/S explota porque necesitamos leer datos del estado en cadena. Esto resultó en miles de dólares en costos de servidor, que el equipo de xDAI cubrió generosamente para nosotros. Sin embargo, esto no es ideal para el largo plazo. Necesitamos un alto rendimiento, no solo para las transacciones escritas por segundo, sino también para las lecturas, como la obtención de datos de la propia cadena de bloques.
También necesitamos una cadena de bloques escalable horizontalmente para evitar el problema del vecino ruidoso. No queremos que un juego popular de repente comience a bloquearse en la cadena de bloques, deteniendo todo el trabajo. También necesitamos flexibilidad y capacidad de personalización para que podamos modificar la máquina de estado para diseñarla para el juego. Esto incluye tener un bucle de juego, hacerlo autoejecutable, etc.
Por último, pero no menos importante, para aquellos que no están familiarizados con la arquitectura de los juegos en línea, esto puede ser un poco vago, necesitamos una alta tasa de ticks. Las garrapatas son la unidad atómica de tiempo en el mundo del juego. En el contexto de las cadenas de bloques, tenemos bloques como unidades atómicas de tiempo. En los juegos, tenemos garrapatas. Esto es casi similar cuando construyes un juego de cadena completa, donde la tasa de generación de ticks o bloques de tu blockchain es igual al tick del juego en sí.
Por lo tanto, lo que necesitamos es una cadena de bloques con alto rendimiento, escalabilidad horizontal, flexibilidad y personalización, y una alta tasa de ticks. Tal diseño puede satisfacer las necesidades de la cadena de bloques que diseñamos desde cero para el juego.
Si tiene una tasa de ticks más alta o más bloques por segundo, el juego se sentirá más receptivo. Por el contrario, si su tasa de ticks es baja, el juego se sentirá lento. Una cosa clave para recordar es que si los fragmentos se retrasan, experimentará un retraso notable en el juego. Esta es una mala experiencia. Si alguna vez has lidiado con jugadores enojados que le gritan a la computadora por perder un juego, esa es una situación absolutamente terrible.
Actualmente, nuestros rollups tienen un bloque por segundo, lo que equivale a un tick. Si queremos tener juegos más geniales, necesitamos tasas de ticks más altas. Por ejemplo, Minecraft, un simple juego de pixel art, tiene 26 tics por segundo. Todavía estamos muy lejos de construir un juego tan receptivo como Minecraft.
Una posible solución es implementar nuestro propio paquete acumulativo. Si bien parece solucionar el problema, en realidad no soluciona la causa raíz del problema. Por ejemplo, tendrá un mayor rendimiento de escritura, pero no al nivel que necesitan los juegos. Por supuesto, si tu juego tiene cien jugadores, esto será suficiente. Sin embargo, si desea crear un juego que requiera un mayor rendimiento, existen restricciones muy estrictas debido a la forma en que se realiza la E/S en la compilación actual.
En el lado de lectura, realmente no obtienes una ganancia de rendimiento. Todavía necesita confiar en los indexadores. Realmente no tienes escalabilidad horizontal. Si intenta iniciar un nuevo paquete acumulativo para escalar horizontalmente su juego, destruirá su ecosistema de contrato inteligente existente. Los mercados implementados por jugadores no funcionarán con otras cadenas que lance para escalar horizontalmente su juego. Esto plantea muchas preguntas.
Finalmente, la alta tasa de ticks y los bloques por segundo siguen siendo un desafío, aunque podemos presionarlo lo más que podamos, podemos obtener dos bloques por segundo, tal vez tres, pero esta es realmente la forma en que funcionan estas cadenas de bloques. más lejos, porque hay un montón de cosas como volver a ordenar que dependen en gran medida de los ciclos de cómputo.
Para responder a esta pregunta, nos remontamos a principios de la década de 2000 y finales de la década de 1990, cuando apenas surgían juegos en línea como los MMO. Tienen un concepto llamado fragmentación. Este no es un concepto nuevo, ha existido en el pasado. La palabra "fragmentación" que usamos en la arquitectura de la base de datos en realidad proviene de una referencia a Ultima Online. Fueron los primeros en usar la palabra "fragmento" para explicar sus diferentes servidores.
Entonces, ¿cómo funciona la fragmentación en los juegos? No es una solución única para todos. Es una herramienta en la caja de herramientas, y la forma en que la adaptes a tu juego variará de un caso a otro. Por ejemplo, la primera construcción de fragmentación es lo que me gusta llamar fragmentación basada en la ubicación. Un buen modelo mental es imaginar un sistema de coordenadas cartesianas dividido en cuatro cuadrantes, cada uno con su propia porción del juego. Cada vez que quieres atravesar un fragmento, envías una comunicación a otro fragmento diciendo "oye, quiero moverme allí" y eres teletransportado a tu fragmento, dejando a los jugadores delante de tu cuerpo. Al hacer esto, distribuye la carga de trabajo del servidor entre varias instancias físicas, en lugar de obligar a un servidor a realizar todos los cálculos para todo el mundo del juego. La segunda configuración es ahora más popular. Se llama fragmentación multiverso, donde tienes varias instancias de juego que se reflejan entre sí. Puede elegir el fragmento al que desea ir, y la carga se equilibra de forma predeterminada para que cada servidor no esté saturado.
Ahora, la pregunta clave es, ¿cómo traes este concepto al resumen? Por eso creamos World Engine. World Engine es nuestra infraestructura insignia, básicamente un clasificador de fragmentos obstinado diseñado para el inicio. El nuestro es diferente y se adapta mejor a nuestras necesidades que muchos de los diseños de clasificadores de fragmentos que hemos visto en las últimas discusiones. La dirección de nuestra optimización es: A, rendimiento, B, queremos asegurarnos de que no haya bloqueos que bloqueen el tiempo de ejecución para garantizar que la tasa de ticks y el tiempo de bloqueo sean lo más eficientes posible, por lo que es sincrónico de forma predeterminada, la forma diseñamos que el clasificador sea una clasificación parcial, en lugar de forzar un pedido total (cada transacción debe ocurrir después de la otra).
Los componentes clave aquí son que tenemos dos cosas principales. Tenemos fragmentación basada en EVM, que es como una cadena EVM pura, en la que los jugadores pueden implementar contratos inteligentes, combinarlos con juegos, crear mercados con impuestos, etc. Es como una cadena normal, ¿verdad? Algo así como un bloque por segundo o algo así, lo suficiente para que puedas hacer todos tus dispositivos y mercados típicos.
El ingrediente secreto aquí es que también usamos un fragmento de juego, que es esencialmente una mini cadena de bloques diseñada como un servidor de juegos de alto rendimiento. Tenemos una interfaz de implementación propia para que pueda personalizar este fragmento a su gusto. Puede construir sus propios fragmentos e inyectarlos en el fragmento base. Solo necesita implementar un conjunto de interfaces estándar, al igual que el Cosmos con el que está familiarizado, Cosmos tiene una interfaz ABC. Básicamente, puede juntar esto en una especificación similar, trayendo sus propios fragmentos a la pila de World Engine.
La clave aquí es que tenemos una alta tasa de verificación que actualmente no podemos lograr con la construcción de fragmentación actual. Aquí es donde quiero presentarles a Cardinal. Cardinal es la primera implementación de fragmentación de juegos de World Engine. Utiliza Entity-Component-System (ECS) con una arquitectura orientada a datos. Esto nos permite paralelizar el juego y aumentar el rendimiento de los cálculos del juego. Tiene una tasa de tictac configurable de hasta 20 tics por segundo. Para la gente de blockchain aquí, eso es 20 bloques por segundo.
También podemos geolocalizarlo para reducir la latencia. Por ejemplo, es posible que tenga un clasificador en los EE. UU. y luego los asiáticos tengan que esperar 300 milisegundos para que la transacción llegue al clasificador. Este es un gran problema en los juegos porque 300 ms es mucho tiempo. Si intentas jugar un juego FPS con un retraso de 200 ms, básicamente, estás muerto.
Otro punto clave que también es importante para nosotros es que es auto indexable. Ya no necesitamos indexadores externos. No necesitamos estos marcos para almacenar en caché el estado del juego. Esto también nos permite crear más juegos en tiempo real sin problemas de latencia, ya que el indexador todavía está tratando de ponerse al día con los bloques de clasificación.
También tenemos un sistema de complementos que permite a las personas paralelizar la validación ZK, etc. La mejor parte, al menos para mí, es que puedes escribir tu código en Go. Ya no es necesario usar Solidity para que tu juego funcione. Si alguna vez has intentado crear un juego de cadena de bloques con Solidity, ha sido una pesadilla.
Sin embargo, el punto clave de nuestra construcción de fragmentos es que puedes construir cualquier cosa como un fragmento. Son básicamente como un espacio de diseño infinito, como lo que puede ser un fragmento.
Suponiendo que no te gusta escribir el código de tu juego en Go, entonces puedes elegir otras formas. Sin embargo, estamos trabajando en un fragmento de juego de Solidity que le permitirá implementar juegos en Solidity de una manera que ofrezca posibilidades de codificación y retenga muchos de los beneficios de Cardinal. También puede crear un fragmento acuñado de NFT con un mempool único y una construcción de pedido, resolviendo el problema del vecino ruidoso de forma similar a la acuñación básica. Incluso puede crear un fragmento de identidad de juego y usar NFT para representar su identidad de juego, de modo que pueda realizar fácilmente transacciones de identidad de juego a través de NFT en lugar de compartir claves privadas.
Esta es una arquitectura de alto nivel y no entraré en demasiados detalles hoy debido a limitaciones de tiempo. Fundamentalmente, permitimos que los contratos inteligentes de EVM se combinen con fragmentos de juegos mediante el uso de selección y pase personalizados. Creamos un envoltorio alrededor de Geth para permitir la comunicación entre ellos, lo que abre mucho espacio de diseño en ambas direcciones. Estamos sincronizados de forma predeterminada y podemos interoperar sin problemas y de forma componible entre fragmentos sin bloqueos.
Nuestro clasificador compartido es diferente en el sentido de que no utiliza la construcción de secuencias compartidas que prioriza los paquetes atómicos ordenados globalmente, lo que requiere un mecanismo de bloqueo y causa problemas como el bloqueo del subproceso principal, lo que genera velocidades de marcación y tiempos de bloqueo inestables, y el resultado es un retraso en el juego. También impone límites en los tiempos de bloque por fragmento y requiere varias construcciones y criptoeconomía para evitar la denegación de servicio. Hay otro gran problema que no he visto mencionado en muchas construcciones de clasificadores de VCR: si tiene diferentes fragmentos que dependen unos de otros y se bloquean, ¿cómo lo resuelve? Con el diseño asíncrono, esto no es un problema, porque todos hacen lo que quieren hacer y luego lo dejan pasar.
De hecho, los haces atómicos y los roll-ups a través de los fragmentos no suelen ser necesarios. Para nuestro caso de uso, no necesitamos nada que requiera haces atómicos, ni creemos que debamos diseñar nuestros Roll-Ups en torno a la pureza del caso de uso. Esto también trae muchas otras características interesantes. Por ejemplo, cada fragmento de juego podría tener una capa DA separada para la cadena base. Por ejemplo, puede usar el fragmento base para enviar datos a Ethereum, y el fragmento del juego puede enviar datos a Celestia (similar a un comité de disponibilidad de datos). También puede reducir los requisitos de hardware para ejecutar un nodo completo, ya que puede ejecutar el nodo completo Geth del fragmento base por separado, sin ejecutar el nodo del fragmento del juego, lo que facilita la integración con cosas como Alchemy.
Para resumir, quiero ser honesto aquí, mucha gente espera que sus construcciones resuelvan todos sus problemas, pero nosotros no. Creemos que nuestra construcción funciona para nosotros, pero podría no funcionar para su caso de uso. No es realista suponer que nuestras construcciones funcionarán para todos. Para nosotros, se ajustaba a nuestras necesidades y ofrecía un alto rendimiento, escalabilidad horizontal, flexibilidad y altas tasas de ticks, pero no era una cura para el cáncer. Si necesita un protocolo DeFi que requiera componibilidad sincrónica, es posible que esta construcción no sea para usted.
En general, realmente creo en el concepto de una arquitectura blockchain centrada en el ser humano. Al diseñar en torno a roles de usuario y casos de uso específicos, puede hacer mejores concesiones, en lugar de tratar de resolver los problemas de todos. Ha llegado la era del renacimiento y todo el mundo puede diseñar sus propios Roll-Ups para satisfacer sus necesidades específicas, en lugar de depender de una solución general. Creo que deberíamos abrazar la Explosión Cámbrica. No construya roll-ups como la capa uno con talla única porque no está diseñado para resolver el mismo problema en absoluto. Personalmente, espero ver a más personas explorar más el espacio de diseño de Roll-Up para casos de uso. Por ejemplo, ¿cómo sería un Roll-Up diseñado específicamente para el intercambio de activos? ¿Estará basado en la intención? ¿Cómo sería un Roll-Up diseñado específicamente para CLOB (Libro de órdenes de límite central) en cadena? Toma, le entrego el micrófono a MJ. Gracias por su invitación.
Versión inglesa: