! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b4e642b2e9-dd1a6f-69ad2a.webp)
La aplicación Rollup está emergiendo como un claro ganador en el escalado de un conjunto específico de aplicaciones de Ethereum. Estas aplicaciones se benefician de garantías de propiedad sólidas y sin permisos, pero no requieren la interacción simultánea entre todos los usuarios de la aplicación. Los juegos totalmente on-chain son el mejor ejemplo. Los juegos on-chain se benefician de una fuerte propiedad de los activos del juego, lo que permite la participación anónima en el juego y permite la modificación anónima del juego. Aún así, la mayoría de los juegos no requieren que todos los jugadores interactúen al mismo tiempo. Otras aplicaciones que pueden beneficiarse de la estrategia de escalado Rollup de la aplicación son los mercados de NFT, los intercambios perpetuos y la inferencia de IA en cadena.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1dce91a53e-dd1a6f-69ad2a.webp)
El paquete acumulativo de aplicaciones ya es la implementación preferida para muchos de estos casos de uso. Sin embargo, la implementación estándar de Rollup, EVMRollup, todavía tiene importantes limitaciones de escalabilidad. Pueden alcanzar un rendimiento de unas 100 transacciones por segundo. Este rendimiento puede ser suficiente para algunos juegos en cadena, dependiendo del tipo de juego. Sin embargo, la mayoría de los juegos requieren un mayor rendimiento para admitir un gran número de jugadores simultáneos (más de 1000). Este artículo se centra en cómo se escala el paquete acumulativo de aplicaciones para llegar a cientos de miles de participantes simultáneos. Para cada enfoque, discuto el tipo apropiado de aplicación/juego y los desafíos que enfrenta.
Escalar horizontalmente
La escalabilidad horizontal es la forma más sencilla de escalar el paquete acumulativo de aplicaciones. Sin embargo, esta simplicidad se produce a expensas de la componibilidad, lo que los hace adecuados solo para un pequeño subconjunto de aplicaciones, como los juegos para un solo jugador.
La escalabilidad horizontal significa simplemente implementar varios paquetes acumulativos de aplicaciones (Optimistic o ZK) e implementar el mismo contrato inteligente en todos los paquetes acumulativos. El front-end de la aplicación dirige sin problemas al usuario a uno de los resúmenes en función de la capacidad, la ubicación o las opciones específicas de la aplicación. Alt Layer demostró recientemente este concepto al lanzar un juego FOCG escalable de 2048. En la parte frontal del juego, los usuarios pueden elegir a qué Rollup unirse en función de su ubicación geográfica. Debido a su simplicidad y disponibilidad de proveedores de rollup-as-a-service como Caldera, que se encargan de todo el trabajo de infraestructura asociado con el giro y la gestión de estos rollups, este enfoque puede ser fácilmente adoptado por los desarrolladores de juegos.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cf4cf9437a-dd1a6f-69ad2a.webp)
Aun así, hay algunos problemas con el enfoque de extensión de varios rollups. El primer problema es el conmutador de red Rollup. Las billeteras actuales, como Metamask, requieren aprobación manual para conectarse a una nueva red, la instancia Rollup. Esto crea una experiencia de usuario difícil y confusa para los jugadores, ya que los jugadores necesitan conectarse manualmente a múltiples "redes" para jugar el mismo juego. Afortunadamente, esta complejidad se puede borrar con una solución de abstracción de cuentas (AA). Algunos ejemplos son EIP 4337 y monederos integrados como Privy y 0xPass.
Otro desafío es administrar el estado del jugador durante las transiciones entre rollups. En algunos casos, como las caídas de capacidad, es posible que una aplicación necesite consolidar varias instancias consolidadas en una sola instancia para conservar los recursos. En este caso, el estado de todos los jugadores activos debe migrarse a la nueva instancia. Las soluciones de puentes actuales, especialmente los puentes ZK, pueden desempeñar un papel clave en la solución de este problema. Con estas soluciones, puede conectar el estado de juego de un jugador a una nueva instancia de Rollup mientras mantiene la prueba de la validez de ese estado. Sin embargo, es posible que la latencia de las soluciones de puente existentes no sea óptima para los casos de uso de juegos.
Canal de estado ZK
Otra extensión de rollup de aplicaciones que es más adecuada para juegos multijugador, como el póquer, es el canal de estado ZK. En estos juegos, la interacción del jugador se produce entre un pequeño número de jugadores, como de 2 a 10 personas. La jugabilidad entre estos jugadores solo es importante mientras el juego está en marcha. Sin embargo, el resultado final del juego es más importante, ya que afecta el equilibrio de activos de cada jugador. Por lo tanto, es importante almacenar los resultados en una capa de persistencia compartida.
En este caso, el paquete acumulativo de aplicaciones representa una capa de información compartida, donde se almacenan los resultados del juego y donde también existen los activos del juego. Para cada juego en Rollup, puede iniciar un canal de estado ZK para servir el juego. Durante el juego, cada jugador genera transacciones y crea ZKP, demostrando que siguió las reglas del juego. Las pruebas de las interacciones de otros jugadores agregan la prueba anterior mediante pruebas recursivas. Cuando termina el juego, el ZKP final se envía al Rollup de la aplicación para demostrar la validez del juego y el resultado final. El cambio de estado producido por el juego cambia el estado del jugador en el paquete acumulativo de aplicaciones.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-f3acfe5e4d-dd1a6f-69ad2a.webp)
El canal de estado ZK mueve las interacciones del juego fuera de la cadena. Por lo tanto, la actividad y las transacciones en el juego no cuentan para el rendimiento del paquete acumulativo de aplicaciones. Con este enfoque, el paquete acumulativo de aplicaciones puede escalar masivamente para admitir miles de reproductores simultáneos. La transacción para el paquete acumulativo de aplicaciones solo validará las transacciones de ZKP y actualización de estado generadas con un factor de escala de 100-1000x. Varios equipos, incluido Ontropy, han estado desarrollando la tecnología.
Un inconveniente de este enfoque es que requiere que los jugadores ejecuten la lógica del juego en sus propios dispositivos y generen ZKP. A menudo, estas pruebas son ligeras y pueden completarse en segundos con sistemas de pruebas de última generación como Halo2. Sin embargo, esto aún puede conducir a una experiencia de jugador reducida para dispositivos con recursos limitados.
Una de las formas de mitigar este problema es designar a uno de los participantes del canal de estado zk como secuenciador temporal. El secuenciador recibirá la transacción de cada jugador y generará el ZKP correspondiente, compartiendo el ZKP con todos los participantes del canal. Esta modificación se puede considerar como una liquidación ZK L3 de corta duración para el paquete acumulativo de aplicaciones. El equipo de Cartridge implementó esta arquitectura mediante el diseño de un secuenciador dedicado llamado Katana.
El enfoque del canal de estado zk tiene un gran potencial. Sin embargo, hay varios problemas abiertos relacionados con el entorno de ejecución dentro del canal de estado zk y cómo optimizar la prueba recursiva. Los entornos zkEVM actuales no son eficientes, y la mayoría actualmente no soportan la recursividad de prueba. Las alternativas incluyen zkVM ligeras, o incluso usar circuitos zk especializados para manejar la interacción del jugador si el jugador tiene un número limitado de movimientos posibles.
Cambiar el entorno de ejecución
Una tercera forma de ampliar el paquete acumulativo de aplicaciones es cambiar el entorno de ejecución del paquete acumulativo. A pesar de su madurez y abundancia de herramientas de desarrollo de EVM, no son adecuadas para aplicaciones de alto rendimiento como los juegos. Además, el modelo de ejecución y almacenamiento de un solo subproceso de EVM da como resultado un rendimiento reducido, que se puede mejorar a través de mejoras.
La principal ventaja de este enfoque es que para aumentar el rendimiento del paquete acumulativo no es necesario sacrificar la componibilidad ni limitar el número de casos de uso. Este enfoque se puede utilizar 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 las aplicaciones que necesitan acceso a un estado compartido, como AMM, protocolos de préstamo y otras aplicaciones DeFi.
Ampliación de la funcionalidad de EVM con precompilación
En primer lugar, Rollup mantiene la compatibilidad con EVM y supera algunos límites en el rendimiento de direcciones precompiladas. La idea aquí es simple. La precompilación es el movimiento descendente de las operaciones de EVM con uso intensivo de recursos informáticos al nivel de nodo. Una operación que requiere cientos o miles de códigos de operación EVM y consume 100,000+ gas se puede simplificar a una sola operación con una reducción de 100 veces en los costos de gas. La precompilación que amplía el entorno acumulativo a menudo se denomina EVM+. Algunos ejemplos de este enfoque son la compatibilidad con la privacidad en cadena y la compatibilidad con esquemas de firma más eficientes, como las firmas BLS. Por ejemplo, el póquer zkHoldem utiliza operaciones dedicadas a FHE y zk para permitir el reparto y la presentación de cartas privadas. El desarrollo de estas precompilaciones especializadas suele ser un esfuerzo conjunto entre el desarrollador del paquete acumulativo de aplicaciones y el proveedor de Raas que administra la implementación y el mantenimiento de la infraestructura del paquete acumulativo de aplicaciones.
Uso de un entorno de ejecución que no sea EVM
Otra forma de mejorar el entorno de ejecución de Rollup es deshacerse de la EVM. Este enfoque está ganando popularidad entre los nuevos desarrolladores del ecosistema Ethereum, así como entre los desarrolladores que creen que Solidity no es el mejor lenguaje para desarrollar aplicaciones complejas.
Hoy en día, tenemos aplicaciones Rollup que se ejecutan en WASM, SVM, Cairo e incluso en tiempos de ejecución de Linux. La mayoría de estos métodos permiten a los desarrolladores escribir contratos inteligentes utilizando 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 se puede crear compatibilidad con EVM. Por ejemplo, el lápiz óptico de Aributrum utiliza un coprocesador para hacer que el lápiz óptico sea compatible con EVM de contrato. Este diseño acerca el Stylus a la arquitectura EVM+ que a la no EVM.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d1e13024e5-dd1a6f-69ad2a.webp)
Entorno de ejecución mixto
El tercer enfoque, que es particularmente popular entre los FOG, es la mejor característica que combina los dos primeros. Este enfoque combina la compatibilidad de EVM con un entorno de ejecución dedicado que no es de EVM. Los entornos que no son EVM se centran en la ejecución de alto rendimiento de las primitivas principales del juego. La gestión de activos del juego, como las transacciones de NFT en el juego, puede gestionarse mediante contratos estándar de Solidity.
La ventaja de este enfoque es que la compatibilidad con EVM garantiza la alineación con el ecosistema de desarrolladores más amplio y los productos existentes. También permite la composición sin permisos. Los desarrolladores pueden modificar y ampliar la lógica del juego añadiendo contratos inteligentes EVM/Solidity. Al mismo tiempo, los motores de juegos especialmente diseñados que no son EVM logran un alto rendimiento que EVM no puede.
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 independiente, 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 rollup en función de la demanda. Del mismo modo, la arquitectura Keystone de Curio incluye un motor de juego de alto rendimiento con una EVM como entorno de ejecución Rollup. El desafío aquí es lograr una interoperabilidad perfecta entre los motores EVM y los motores de juegos.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-df306665b5-dd1a6f-69ad2a.webp)
Consideraciones sobre la disponibilidad de datos
En la discusión anterior, la atención se centró en aumentar el rendimiento de las transacciones consolidadas, que es el aspecto principal del escalado de la acumulación de aplicaciones. Otros temas relacionados con este aumento del rendimiento son la disponibilidad de datos (DA), la descentralización de los pedidos y la velocidad de liquidación. En el caso de los paquetes acumulativos de aplicaciones de alto rendimiento, la disponibilidad de datos es el más acuciante de estos problemas.
Un paquete acumulativo de una sola aplicación puede tener un rendimiento de más de 10 000 transacciones por segundo. Es imposible utilizar Ethereum como capa de disponibilidad de datos para estas transacciones. En primer lugar, el coste medio de publicar datos simples de transferencia de ETH de L2 en L2 puede superar los 0,1 dólares. Estos costos son demasiado altos para la mayoría de los paquetes acumulativos de aplicaciones. Además, la L1 de Ethereum no puede admitir actualmente rollups que aprovechen la L1 para la disponibilidad de datos con unas 8.000 transacciones por segundo.
Los paquetes acumulativos de aplicaciones se basarán principalmente en soluciones DA externas. Celestia y EigenDA se posicionan actualmente como las opciones más viables para la aplicación Rollup. Por ejemplo, Eclipse planea utilizar Celestia como capa de disponibilidad de datos para su paquete acumulativo base de SVM de alto rendimiento. También se planea que Argus y los motores de juegos de alto rendimiento usen inicialmente Celestia. Del mismo modo, EigenDA promete un rendimiento de datos de hasta 10 MB por segundo y también puede proporcionar una solución viable para múltiples paquetes acumulativos de aplicaciones.
Sin embargo, la principal desventaja de integrar Celestia o EigneDA es la fuga de valor económico. Los paquetes acumulativos de aplicaciones deben pagar las tarifas de la capa DA, así como las tarifas de liquidación en Ethereum L1. La tarifa de liquidación es clave para la aplicación Rollup porque vincula la seguridad de Rollup a la seguridad de Ethereum. Las garantías DA son menos importantes en el contexto de FOG, donde el valor de la transacción es mucho menor que el de estas redes. Además, Celestia y EigenDA prometen tarifas bajas porque estas redes están en funcionamiento y la utilización será baja inicialmente. Cuando estas redes DA alcanzan una alta utilización, los cargos DA también pueden llegar a ser prohibitivos. En mi opinión, el paquete acumulativo de aplicaciones debe usar una placa de disponibilidad de datos (DAC) simple para demostrar la disponibilidad de los datos consolidados.
En conclusión, creo que los paquetes acumulativos de aplicaciones son la mejor solución existente para escalar aplicaciones de alto rendimiento, especialmente juegos totalmente en cadena. Ampliar estas aplicaciones con Rollup es clave para lograr una adopción generalizada más allá de los usuarios nativos de criptomonedas.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?
Escrito por Mohamed Fouda
Compilado: DeepTide TechFlow
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b4e642b2e9-dd1a6f-69ad2a.webp)
La aplicación Rollup está emergiendo como un claro ganador en el escalado de un conjunto específico de aplicaciones de Ethereum. Estas aplicaciones se benefician de garantías de propiedad sólidas y sin permisos, pero no requieren la interacción simultánea entre todos los usuarios de la aplicación. Los juegos totalmente on-chain son el mejor ejemplo. Los juegos on-chain se benefician de una fuerte propiedad de los activos del juego, lo que permite la participación anónima en el juego y permite la modificación anónima del juego. Aún así, la mayoría de los juegos no requieren que todos los jugadores interactúen al mismo tiempo. Otras aplicaciones que pueden beneficiarse de la estrategia de escalado Rollup de la aplicación son los mercados de NFT, los intercambios perpetuos y la inferencia de IA en cadena.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-1dce91a53e-dd1a6f-69ad2a.webp)
El paquete acumulativo de aplicaciones ya es la implementación preferida para muchos de estos casos de uso. Sin embargo, la implementación estándar de Rollup, EVMRollup, todavía tiene importantes limitaciones de escalabilidad. Pueden alcanzar un rendimiento de unas 100 transacciones por segundo. Este rendimiento puede ser suficiente para algunos juegos en cadena, dependiendo del tipo de juego. Sin embargo, la mayoría de los juegos requieren un mayor rendimiento para admitir un gran número de jugadores simultáneos (más de 1000). Este artículo se centra en cómo se escala el paquete acumulativo de aplicaciones para llegar a cientos de miles de participantes simultáneos. Para cada enfoque, discuto el tipo apropiado de aplicación/juego y los desafíos que enfrenta.
Escalar horizontalmente
La escalabilidad horizontal es la forma más sencilla de escalar el paquete acumulativo de aplicaciones. Sin embargo, esta simplicidad se produce a expensas de la componibilidad, lo que los hace adecuados solo para un pequeño subconjunto de aplicaciones, como los juegos para un solo jugador.
La escalabilidad horizontal significa simplemente implementar varios paquetes acumulativos de aplicaciones (Optimistic o ZK) e implementar el mismo contrato inteligente en todos los paquetes acumulativos. El front-end de la aplicación dirige sin problemas al usuario a uno de los resúmenes en función de la capacidad, la ubicación o las opciones específicas de la aplicación. Alt Layer demostró recientemente este concepto al lanzar un juego FOCG escalable de 2048. En la parte frontal del juego, los usuarios pueden elegir a qué Rollup unirse en función de su ubicación geográfica. Debido a su simplicidad y disponibilidad de proveedores de rollup-as-a-service como Caldera, que se encargan de todo el trabajo de infraestructura asociado con el giro y la gestión de estos rollups, este enfoque puede ser fácilmente adoptado por los desarrolladores de juegos.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cf4cf9437a-dd1a6f-69ad2a.webp)
Aun así, hay algunos problemas con el enfoque de extensión de varios rollups. El primer problema es el conmutador de red Rollup. Las billeteras actuales, como Metamask, requieren aprobación manual para conectarse a una nueva red, la instancia Rollup. Esto crea una experiencia de usuario difícil y confusa para los jugadores, ya que los jugadores necesitan conectarse manualmente a múltiples "redes" para jugar el mismo juego. Afortunadamente, esta complejidad se puede borrar con una solución de abstracción de cuentas (AA). Algunos ejemplos son EIP 4337 y monederos integrados como Privy y 0xPass.
Otro desafío es administrar el estado del jugador durante las transiciones entre rollups. En algunos casos, como las caídas de capacidad, es posible que una aplicación necesite consolidar varias instancias consolidadas en una sola instancia para conservar los recursos. En este caso, el estado de todos los jugadores activos debe migrarse a la nueva instancia. Las soluciones de puentes actuales, especialmente los puentes ZK, pueden desempeñar un papel clave en la solución de este problema. Con estas soluciones, puede conectar el estado de juego de un jugador a una nueva instancia de Rollup mientras mantiene la prueba de la validez de ese estado. Sin embargo, es posible que la latencia de las soluciones de puente existentes no sea óptima para los casos de uso de juegos.
Canal de estado ZK
Otra extensión de rollup de aplicaciones que es más adecuada para juegos multijugador, como el póquer, es el canal de estado ZK. En estos juegos, la interacción del jugador se produce entre un pequeño número de jugadores, como de 2 a 10 personas. La jugabilidad entre estos jugadores solo es importante mientras el juego está en marcha. Sin embargo, el resultado final del juego es más importante, ya que afecta el equilibrio de activos de cada jugador. Por lo tanto, es importante almacenar los resultados en una capa de persistencia compartida.
En este caso, el paquete acumulativo de aplicaciones representa una capa de información compartida, donde se almacenan los resultados del juego y donde también existen los activos del juego. Para cada juego en Rollup, puede iniciar un canal de estado ZK para servir el juego. Durante el juego, cada jugador genera transacciones y crea ZKP, demostrando que siguió las reglas del juego. Las pruebas de las interacciones de otros jugadores agregan la prueba anterior mediante pruebas recursivas. Cuando termina el juego, el ZKP final se envía al Rollup de la aplicación para demostrar la validez del juego y el resultado final. El cambio de estado producido por el juego cambia el estado del jugador en el paquete acumulativo de aplicaciones.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-f3acfe5e4d-dd1a6f-69ad2a.webp)
El canal de estado ZK mueve las interacciones del juego fuera de la cadena. Por lo tanto, la actividad y las transacciones en el juego no cuentan para el rendimiento del paquete acumulativo de aplicaciones. Con este enfoque, el paquete acumulativo de aplicaciones puede escalar masivamente para admitir miles de reproductores simultáneos. La transacción para el paquete acumulativo de aplicaciones solo validará las transacciones de ZKP y actualización de estado generadas con un factor de escala de 100-1000x. Varios equipos, incluido Ontropy, han estado desarrollando la tecnología.
Un inconveniente de este enfoque es que requiere que los jugadores ejecuten la lógica del juego en sus propios dispositivos y generen ZKP. A menudo, estas pruebas son ligeras y pueden completarse en segundos con sistemas de pruebas de última generación como Halo2. Sin embargo, esto aún puede conducir a una experiencia de jugador reducida para dispositivos con recursos limitados.
Una de las formas de mitigar este problema es designar a uno de los participantes del canal de estado zk como secuenciador temporal. El secuenciador recibirá la transacción de cada jugador y generará el ZKP correspondiente, compartiendo el ZKP con todos los participantes del canal. Esta modificación se puede considerar como una liquidación ZK L3 de corta duración para el paquete acumulativo de aplicaciones. El equipo de Cartridge implementó esta arquitectura mediante el diseño de un secuenciador dedicado llamado Katana.
El enfoque del canal de estado zk tiene un gran potencial. Sin embargo, hay varios problemas abiertos relacionados con el entorno de ejecución dentro del canal de estado zk y cómo optimizar la prueba recursiva. Los entornos zkEVM actuales no son eficientes, y la mayoría actualmente no soportan la recursividad de prueba. Las alternativas incluyen zkVM ligeras, o incluso usar circuitos zk especializados para manejar la interacción del jugador si el jugador tiene un número limitado de movimientos posibles.
Cambiar el entorno de ejecución
Una tercera forma de ampliar el paquete acumulativo de aplicaciones es cambiar el entorno de ejecución del paquete acumulativo. A pesar de su madurez y abundancia de herramientas de desarrollo de EVM, no son adecuadas para aplicaciones de alto rendimiento como los juegos. Además, el modelo de ejecución y almacenamiento de un solo subproceso de EVM da como resultado un rendimiento reducido, que se puede mejorar a través de mejoras.
La principal ventaja de este enfoque es que para aumentar el rendimiento del paquete acumulativo no es necesario sacrificar la componibilidad ni limitar el número de casos de uso. Este enfoque se puede utilizar 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 las aplicaciones que necesitan acceso a un estado compartido, como AMM, protocolos de préstamo y otras aplicaciones DeFi.
Ampliación de la funcionalidad de EVM con precompilación
En primer lugar, Rollup mantiene la compatibilidad con EVM y supera algunos límites en el rendimiento de direcciones precompiladas. La idea aquí es simple. La precompilación es el movimiento descendente de las operaciones de EVM con uso intensivo de recursos informáticos al nivel de nodo. Una operación que requiere cientos o miles de códigos de operación EVM y consume 100,000+ gas se puede simplificar a una sola operación con una reducción de 100 veces en los costos de gas. La precompilación que amplía el entorno acumulativo a menudo se denomina EVM+. Algunos ejemplos de este enfoque son la compatibilidad con la privacidad en cadena y la compatibilidad con esquemas de firma más eficientes, como las firmas BLS. Por ejemplo, el póquer zkHoldem utiliza operaciones dedicadas a FHE y zk para permitir el reparto y la presentación de cartas privadas. El desarrollo de estas precompilaciones especializadas suele ser un esfuerzo conjunto entre el desarrollador del paquete acumulativo de aplicaciones y el proveedor de Raas que administra la implementación y el mantenimiento de la infraestructura del paquete acumulativo de aplicaciones.
Uso de un entorno de ejecución que no sea EVM
Otra forma de mejorar el entorno de ejecución de Rollup es deshacerse de la EVM. Este enfoque está ganando popularidad entre los nuevos desarrolladores del ecosistema Ethereum, así como entre los desarrolladores que creen que Solidity no es el mejor lenguaje para desarrollar aplicaciones complejas.
Hoy en día, tenemos aplicaciones Rollup que se ejecutan en WASM, SVM, Cairo e incluso en tiempos de ejecución de Linux. La mayoría de estos métodos permiten a los desarrolladores escribir contratos inteligentes utilizando 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 se puede crear compatibilidad con EVM. Por ejemplo, el lápiz óptico de Aributrum utiliza un coprocesador para hacer que el lápiz óptico sea compatible con EVM de contrato. Este diseño acerca el Stylus a la arquitectura EVM+ que a la no EVM.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d1e13024e5-dd1a6f-69ad2a.webp)
Entorno de ejecución mixto
El tercer enfoque, que es particularmente popular entre los FOG, es la mejor característica que combina los dos primeros. Este enfoque combina la compatibilidad de EVM con un entorno de ejecución dedicado que no es de EVM. Los entornos que no son EVM se centran en la ejecución de alto rendimiento de las primitivas principales del juego. La gestión de activos del juego, como las transacciones de NFT en el juego, puede gestionarse mediante contratos estándar de Solidity.
La ventaja de este enfoque es que la compatibilidad con EVM garantiza la alineación con el ecosistema de desarrolladores más amplio y los productos existentes. También permite la composición sin permisos. Los desarrolladores pueden modificar y ampliar la lógica del juego añadiendo contratos inteligentes EVM/Solidity. Al mismo tiempo, los motores de juegos especialmente diseñados que no son EVM logran un alto rendimiento que EVM no puede.
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 independiente, 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 rollup en función de la demanda. Del mismo modo, la arquitectura Keystone de Curio incluye un motor de juego de alto rendimiento con una EVM como entorno de ejecución Rollup. El desafío aquí es lograr una interoperabilidad perfecta entre los motores EVM y los motores de juegos.
! [Interpretación de la tecnología Dapp Rollup: ¿Cómo hacer que la aplicación de alto rendimiento se generalice?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-df306665b5-dd1a6f-69ad2a.webp)
Consideraciones sobre la disponibilidad de datos
En la discusión anterior, la atención se centró en aumentar el rendimiento de las transacciones consolidadas, que es el aspecto principal del escalado de la acumulación de aplicaciones. Otros temas relacionados con este aumento del rendimiento son la disponibilidad de datos (DA), la descentralización de los pedidos y la velocidad de liquidación. En el caso de los paquetes acumulativos de aplicaciones de alto rendimiento, la disponibilidad de datos es el más acuciante de estos problemas.
Un paquete acumulativo de una sola aplicación puede tener un rendimiento de más de 10 000 transacciones por segundo. Es imposible utilizar Ethereum como capa de disponibilidad de datos para estas transacciones. En primer lugar, el coste medio de publicar datos simples de transferencia de ETH de L2 en L2 puede superar los 0,1 dólares. Estos costos son demasiado altos para la mayoría de los paquetes acumulativos de aplicaciones. Además, la L1 de Ethereum no puede admitir actualmente rollups que aprovechen la L1 para la disponibilidad de datos con unas 8.000 transacciones por segundo.
Los paquetes acumulativos de aplicaciones se basarán principalmente en soluciones DA externas. Celestia y EigenDA se posicionan actualmente como las opciones más viables para la aplicación Rollup. Por ejemplo, Eclipse planea utilizar Celestia como capa de disponibilidad de datos para su paquete acumulativo base de SVM de alto rendimiento. También se planea que Argus y los motores de juegos de alto rendimiento usen inicialmente Celestia. Del mismo modo, EigenDA promete un rendimiento de datos de hasta 10 MB por segundo y también puede proporcionar una solución viable para múltiples paquetes acumulativos de aplicaciones.
Sin embargo, la principal desventaja de integrar Celestia o EigneDA es la fuga de valor económico. Los paquetes acumulativos de aplicaciones deben pagar las tarifas de la capa DA, así como las tarifas de liquidación en Ethereum L1. La tarifa de liquidación es clave para la aplicación Rollup porque vincula la seguridad de Rollup a la seguridad de Ethereum. Las garantías DA son menos importantes en el contexto de FOG, donde el valor de la transacción es mucho menor que el de estas redes. Además, Celestia y EigenDA prometen tarifas bajas porque estas redes están en funcionamiento y la utilización será baja inicialmente. Cuando estas redes DA alcanzan una alta utilización, los cargos DA también pueden llegar a ser prohibitivos. En mi opinión, el paquete acumulativo de aplicaciones debe usar una placa de disponibilidad de datos (DAC) simple para demostrar la disponibilidad de los datos consolidados.
En conclusión, creo que los paquetes acumulativos de aplicaciones son la mejor solución existente para escalar aplicaciones de alto rendimiento, especialmente juegos totalmente en cadena. Ampliar estas aplicaciones con Rollup es clave para lograr una adopción generalizada más allá de los usuarios nativos de criptomonedas.