Cómo escalar los paquetes acumulativos de aplicaciones

Los paquetes acumulativos de aplicaciones se están convirtiendo en el claro ganador a la hora de escalar un conjunto específico de aplicaciones de Ethereum. Estas aplicaciones se benefician de sólidas garantías de propiedad sin permiso, pero no requieren interacciones simultáneas entre todos los usuarios de la aplicación. Los juegos totalmente en cadena (FOG) son el mejor ejemplo que se ajusta a esta descripción. Los FOG se benefician de una sólida propiedad de activos en el juego, participación en juegos sin permiso y modificación de juegos sin permiso. Aún así, la mayoría de los juegos no requieren que todos los jugadores interactúen entre sí al mismo tiempo. Otras aplicaciones que pueden beneficiarse de las estrategias de escalamiento acumulativo de aplicaciones incluyen los mercados NFT, los intercambios perpetuos y la inferencia de IA en cadena.

Los paquetes acumulativos de aplicaciones ya son la implementación de referencia para muchos de estos casos de uso. Sin embargo, las implementaciones de paquetes acumulativos estándar, es decir, paquetes acumulativos de EVM, todavía tienen importantes límites de escalabilidad. Probablemente puedan alcanzar rendimientos de alrededor de 100 transacciones por segundo. Este rendimiento puede ser suficiente para algunos juegos en cadena, según el tipo de juego. Sin embargo, la mayoría de los juegos necesitan un rendimiento mucho mayor para admitir una gran cantidad (> 1000) de jugadores simultáneos. Este artículo se centra en los enfoques para ampliar los paquetes acumulativos de aplicaciones para llegar a cientos de miles de participantes simultáneos. Para cada enfoque, analizo el tipo adecuado de aplicaciones/juegos y los desafíos que enfrenta.

Se recomienda a los desarrolladores que utilizan paquetes acumulativos de aplicaciones o aquellos que están creando la infraestructura para ampliar los paquetes acumulativos de aplicaciones a comunicarse conmigo y presentar su solicitud a Alliance. Espero trabajar con fundadores construyendo en estas áreas.

Escala horizontal

La escalabilidad horizontal es el enfoque más sencillo para escalar los paquetes acumulativos de aplicaciones. Sin embargo, la simplicidad se consigue a expensas de la pérdida de componibilidad, lo que los hace adecuados sólo para un pequeño conjunto de aplicaciones, como juegos para un solo jugador.

La escalabilidad horizontal significa simplemente implementar múltiples paquetes acumulativos de aplicaciones (OP o ZK) con el mismo contrato inteligente implementado en todos los paquetes acumulativos. La interfaz de la aplicación dirige sin problemas al usuario a uno de los paquetes acumulativos según la capacidad, la ubicación o las opciones específicas de la aplicación. Alt Layer demostró recientemente este concepto al lanzar un FOCG 2048 escalable. En la interfaz del juego, el usuario tiene la opción de seleccionar a qué grupo unirse según su ubicación geográfica. Debido a la simplicidad y disponibilidad de los proveedores de paquetes acumulativos como servicio, como Caldera, que manejan todo el trabajo de infraestructura relacionado con el giro y la administración de estos paquetes acumulativos, los desarrolladores de juegos pueden adoptar fácilmente este enfoque.

A pesar de la simplicidad, existen algunos problemas en el enfoque de escalamiento multi-rollup. El primero es la conmutación de red acumulada. Las billeteras actuales, por ejemplo, Metamask, requieren aprobación manual para conectarse a una nueva red, es decir, una instancia acumulada. Esto genera una experiencia de usuario difícil y confusa para los jugadores que necesitan conectarse manualmente a múltiples “redes” para jugar el mismo juego. Afortunadamente, es posible eliminar esta complejidad con las soluciones AA. Es decir, EIP 4337 y billeteras integradas como Privy y 0xPass.

Otro desafío es la gestión del estado de los jugadores durante una transición entre acumulaciones. En algunos casos, por ejemplo, caídas de capacidad, es posible que la aplicación necesite consolidar varias instancias acumuladas en una sola instancia para ahorrar recursos. En tal caso, es necesario migrar todo el estado del jugador activo a la nueva instancia. Las soluciones de puentes actuales, específicamente los puentes zk, pueden ser fundamentales para resolver este problema. Con estas soluciones, es posible conectar el estado del juego del jugador con una nueva instancia acumulativa manteniendo al mismo tiempo una prueba de la validez de este estado. Sin embargo, la latencia de las soluciones puente existentes puede ser menos óptima para los casos de uso de juegos.

Canales estatales de ZK

Otro enfoque de escalamiento acumulativo de aplicaciones que es más adecuado para juegos multijugador, por ejemplo, póquer, son los canales estatales zk. En estos juegos, las interacciones entre los jugadores ocurren entre un pequeño número de jugadores, por ejemplo, de 2 a 10. El juego entre estos jugadores sólo es importante mientras el juego avanza. Sin embargo, el resultado final del juego es más importante porque afecta el equilibrio de activos de cada jugador. Por lo tanto, es importante almacenar el resultado en una capa persistente compartida.

En este caso, el paquete acumulativo de aplicaciones representa la capa de información compartida donde se almacenan los resultados del juego y donde existen los recursos del juego. Para cada juego del resumen, se puede iniciar un canal estatal ZK para ofrecer este juego. Durante el juego, cada jugador genera transacciones y crea un ZKP que demuestra que ha seguido las reglas del juego. Las pruebas de las interacciones de otros jugadores agregan pruebas anteriores mediante pruebas recursivas. Cuando finaliza el juego, el ZKP final se envía al paquete acumulativo de aplicaciones para demostrar la validez del juego y la validez del resultado final. El cambio de estado resultante del juego cambia los estados del jugador en el paquete acumulativo de aplicaciones.

Los canales estatales de ZK mueven las interacciones del juego fuera de la cadena. Por lo tanto, las actividades y transacciones dentro del juego no cuentan para el rendimiento del paquete acumulativo de aplicaciones. Con este enfoque, los paquetes acumulativos de aplicaciones pueden escalar masivamente para admitir decenas o cientos de miles de jugadores simultáneos. Las transacciones acumuladas de la aplicación serán solo la verificación de los ZKP generados y las transacciones de actualización del estado, lo que dará como resultado un factor de escala de 100 a 1000x. Varios equipos, incluido Ontropy , se han centrado en desarrollar esta tecnología.

Una desventaja de este enfoque es que requiere que los jugadores ejecuten la lógica del juego y generen los ZKP en sus dispositivos. A menudo, estas pruebas son ligeras y, al aprovechar sistemas de prueba de última generación como Halo2, la prueba puede tardar menos de unos segundos. Sin embargo, esto aún puede provocar una experiencia de usuario degradada para jugadores con dispositivos con recursos limitados.

Una modificación de este enfoque que puede aliviar este problema es asignar uno de los participantes del canal de estado zk como secuenciador temporal. Este secuenciador recibirá las transacciones de cada jugador, generará los ZKP correspondientes y compartirá el ZKP con todos los participantes del canal. Esta modificación puede considerarse como ZK L3 efímeras que se instalan en el paquete acumulativo de aplicaciones. El equipo de Cartucho ha estado implementando esta arquitectura mediante el diseño de un secuenciador especializado llamado Katana.

El enfoque del canal estatal zk tiene un gran potencial. Sin embargo, hay varias preguntas abiertas relacionadas con el entorno de ejecución dentro del canal de estado zk y cómo optimizarlo para la recursión de prueba. Los entornos zkEVM actuales no son muy eficientes y la mayoría de ellos actualmente no admiten la recursividad de prueba. Las alternativas incluyen zkVM livianos o incluso el uso de circuitos zk especializados para las interacciones del jugador si la cantidad de acciones posibles para el jugador es limitada.

Cambiar el entorno de ejecución

Un tercer enfoque para la escalabilidad del paquete acumulativo de aplicaciones es cambiar el entorno de ejecución del paquete acumulativo. A pesar de la madurez y abundancia de las herramientas de desarrollo EVM, no son adecuadas para aplicaciones de alto rendimiento como los juegos. Además, el modelo de almacenamiento y ejecución de subproceso único EVM conduce a un rendimiento reducido que se puede mejorar.

La principal ventaja de este enfoque es que mejorar el rendimiento del resumen no requiere sacrificar la componibilidad ni restringir la cantidad de casos de uso. Este enfoque puede funcionar para cualquier aplicación Web 3 siempre que el entorno de ejecución pueda alcanzar el rendimiento requerido por la aplicación. Esto los convierte en la única solución viable para aplicaciones que requieren acceder a un estado compartido como AMM, protocolos de préstamos y otras aplicaciones DeFi.

Ampliación de la funcionalidad EVM mediante precompilaciones

El primer enfoque es que el paquete acumulativo siga siendo compatible con EVM y solucione algunas de las limitaciones de rendimiento mediante precompilaciones. La idea aquí es simple. Una precompilación consiste simplemente en mover operaciones EVM computacionalmente costosas al nivel de nodo. Una operación que requeriría cientos o miles de OP de EVM y consumiría más de 100.000 gases se puede simplificar en una sola operación con costos de gas 100 veces menores. La expansión del entorno acumulativo con precompilaciones a menudo se denomina EVM+. Ejemplos de este enfoque incluyen el apoyo a la privacidad en cadena y el apoyo a esquemas de firma más eficientes, por ejemplo, firmas BLS. Por ejemplo, el juego de póquer zkHoldem utiliza operaciones especializadas FHE y zk para lograr la negociación y revelación de cartas de póquer privadas. El desarrollo de estas precompilaciones especializadas es a menudo un esfuerzo compartido entre el desarrollador de paquetes acumulativos de aplicaciones y los proveedores de Raas que gestionan la implementación y el mantenimiento de la infraestructura de paquetes acumulativos de aplicaciones.

Usar un entorno de ejecución que no sea EVM

Otro enfoque para mejorar el entorno de ejecución de paquetes acumulativos es liberarse del EVM. Este enfoque se está volviendo más popular entre los desarrolladores que son nuevos en el ecosistema Ethereum y los desarrolladores que creen que Solidity no es el mejor lenguaje para desarrollar aplicaciones complejas.

Hoy en día tenemos aplicaciones acumulativas que se ejecutan en tiempos de ejecución WASM, SVM, Cairo e incluso Linux. La mayoría de estos enfoques permiten a los desarrolladores escribir su contrato inteligente en lenguajes de alto nivel como Rust o C. La desventaja es que a menudo se pierde la interoperabilidad con los contratos de Solidity existentes. Sin embargo, aún es posible crear compatibilidad con EVM. Por ejemplo, el lápiz óptico de Aributrum emplea un coprocesador para hacer que los contratos Stylus sean compatibles con el EVM. Este diseño acerca a Stylus a una arquitectura EVM+ que a una que no es EVM.

Entornos de ejecución híbridos

Un tercer enfoque que es particularmente popular dentro de los FOG es combinar las mejores características de los dos enfoques anteriores. Este enfoque combina la compatibilidad con EVM con el entorno de ejecución especializado que no es EVM. Los entornos que no son EVM se centran en la ejecución de alto rendimiento de las primitivas centrales del juego. La gestión de activos en el juego, por ejemplo, el comercio de NFT en el juego, se puede gestionar mediante contratos estándar de Solidity.

La ventaja de este enfoque es que la compatibilidad con EVM garantiza la alineación con un ecosistema más amplio de desarrolladores y productos existentes. También permite la componibilidad sin permiso. Los desarrolladores pueden modificar y ampliar la lógica del juego agregando contratos inteligentes de solidez/EVM. Mientras tanto, el motor de juego especializado que no es EVM logra un alto rendimiento que el EVM no puede satisfacer.

Ejemplos de este enfoque son World Engine de Argus y Keystone de Curio. World Engine separa la ejecución de la lógica del juego en una capa separada llamada Game Shard que se ejecuta sobre la capa compatible con EVM. Game Shard también está diseñado para permitir el escalado horizontal para ajustar el rendimiento total del resumen según la demanda. De manera similar, la arquitectura Keystone de Curio incluye un motor de juego de alto rendimiento con EVM como entorno de ejecución acumulativo. El desafío aquí es lograr una interoperabilidad perfecta entre el motor EVM y el motor del juego.

Consideraciones sobre la disponibilidad de datos

En la discusión anterior, la atención se centró en el aspecto principal de escalar los paquetes acumulativos de aplicaciones, que es aumentar el rendimiento de las transacciones acumuladas. Hay otros temas relacionados con este mayor rendimiento, como la disponibilidad de datos (DA), la descentralización del secuenciador y la velocidad de liquidación. La disponibilidad de datos es el más apremiante de estos problemas para los paquetes acumulativos de aplicaciones de alto rendimiento.

Un único paquete acumulativo de aplicaciones puede alcanzar potencialmente rendimientos superiores a 10 000 tps. No es posible utilizar Ethereum como capa DA para estas transacciones. En primer lugar, el coste medio de publicar los datos de una simple transferencia ETH L2 en L1 puede superar los 0,10 dólares. Estos costos son demasiado altos para la mayoría de los paquetes acumulativos de aplicaciones. Más importante aún, el L1 de Ethereum actualmente no puede admitir más de aproximadamente 8k TPS [1] para paquetes acumulativos que usan el L1 para DA.

Los paquetes acumulativos de aplicaciones dependerán principalmente de soluciones DA externas. Celestia y EigenDA se posicionan actualmente como la opción más viable para los paquetes acumulativos de aplicaciones. Por ejemplo, Eclipse planea utilizar Celestia para su paquete acumulativo de alto rendimiento basado en SVM. Argus y los motores de juegos de alto rendimiento también planean utilizar Celestia inicialmente. De manera similar, EigenDA, que promete un rendimiento de datos de hasta 10 MB/s, puede ser una solución viable para múltiples acumulaciones de aplicaciones.

Sin embargo, la integración de Celestia o EigneDA tiene la principal desventaja de la fuga de valor económico. El paquete acumulativo de aplicaciones tiene que pagar tarifas por la capa DA además de las tarifas de liquidación en Ethereum L1. Las tarifas de liquidación son fundamentales para el paquete acumulativo de aplicaciones porque alinean la seguridad del paquete acumulativo con la seguridad de Ethereum. Las garantías DA son menos importantes, especialmente en el contexto de FOG, donde los valores de transacción son mucho más pequeños. Además, Celestia y EigenDA prometen tarifas bajas porque estas redes son nuevas e inicialmente tendrán una baja utilización. Cuando estas redes DA logran una alta utilización, las tarifas de DA también pueden volverse excesivas. En mi opinión, los paquetes acumulativos de aplicaciones deberían utilizar un Comité de disponibilidad de datos (DAC) simple para dar fe de la disponibilidad de los datos acumulados[3] .

En conclusión, creo que los paquetes acumulativos de aplicaciones son la mejor solución existente para escalar aplicaciones de alto rendimiento en general y juegos totalmente en cadena en particular. Ampliar estos paquetes acumulativos de aplicaciones es la clave para lograr una adopción generalizada que vaya más allá de los usuarios criptográficos nativos. En Alliance, queremos hacer realidad esta visión apoyando a los fundadores que están construyendo esta

Me gustaría agradecer a Matt Katz, Kevin Zhang, Tarrence van As y Larry Liu por sus valiosos comentarios sobre este artículo.

[1] Se supone que el 50% del límite de gas de bloque de Ethereum será solo para almacenar datos utilizando calldata, con un tamaño de transmisión promedio de 10 bytes. Tiempos de bloque de 12 segundos

Descargo de responsabilidad:

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