Rollups específicos de la aplicación: el equilibrio entre conectividad y control

Hace dos años, los desarrolladores de aplicaciones se enfrentaron a una elección relativamente sencilla a la hora de decidir en qué cadena desplegar su aplicación: Ethereum, Solana, Cosmos y quizás algunas otras cadenas de capa 1. En ese momento, los Rollups aún no estaban operativos y pocas personas habían oído hablar del término “pila modular”. Las diferencias entre estas cadenas L1 (rendimiento, tarifas, etc.) son muy notables y relativamente fáciles de entender.

Hoy, la situación es muy diferente. Los desarrolladores de aplicaciones se enfrentan a más opciones: cadenas L1, rollups de uso general (incluidos op y zk), infraestructura IBC avanzada, proveedor de rollups como servicio, appchains y más. A medida que aumentan las opciones, también lo hacen las preguntas, que incluyen:

• ¿Debe el equipo implementar en un paquete acumulativo genérico o crear un paquete acumulativo específico de la aplicación?
• Si eliges un rollup genérico, ¿cuál eliges?
• Si opta por el paquete acumulativo de aplicaciones, ¿qué SDK o paquete acumulativo como servicio usar?
• ¿Qué nivel de disponibilidad de datos elegir?
• ¿Es útil EigenLayer?
• ¿Cómo considerar un secuenciador?
• Si elijo la ruta de OP Stack, ¿seguirá habiendo un “gesto de orbe de color” en el ecosistema Superchain de Optimism?

¡Todo es abrumador!

Para acotar el problema, este artículo partirá de la perspectiva de una aplicación que ya está desplegada en Ethereum y quiere escalar dentro del ecosistema de Ethereum. Por lo tanto, la atención se centrará en las decisiones a las que se enfrentan los equipos de aplicaciones a la hora de decidir si lanzar o no sus propios paquetes acumulativos, qué tipos de aplicaciones son especialmente adecuadas para este tipo de infraestructura y cuándo podríamos llegar a un punto de inflexión para la adopción.

Un marco general

En el centro de la decisión de usar o no un rollup específico de la aplicación hay una pregunta simple: si la aplicación se ejecutara en su propia cadena, ¿el usuario la seguiría usando?

• Si la aplicación se ejecuta en su propia cadena, ¿es más probable que los usuarios la usen?
• Si la aplicación se ejecuta en su propia cadena, ¿sigue siendo la misma posibilidad de que los usuarios la usen?

Los beneficios de los rollups específicos de la aplicación se derivan de un mayor control: la capacidad de abstraer los costos de gas, limitar la congestión en la cadena causada por otras actividades de la aplicación, experimentar mejor con la forma de usar tokens, explorar diferentes estructuras económicas (por ejemplo, reembolsos de gas para integraciones), crear entornos de ejecución personalizados, implementar controles de acceso (por ejemplo, implementaciones de permisos) y más.

Pero este mayor control se produce a costa de la conectividad con el ecosistema más amplio. Las aplicaciones en una cadena compartida/universal pueden disfrutar de la liquidez que ya está en la cadena (por ejemplo, sin necesidad de puentes adicionales entre cadenas), la componibilidad con otras aplicaciones y la atención de los usuarios que ya están enfocados en la cadena. La creación de una cadena genérica también requiere menos esfuerzo de desarrollo interno que una aplicación que ejecuta su propia cadena.

Si no hay un costo para un mayor control, es probable que mejore la experiencia del usuario. Por lo tanto, la respuesta a la pregunta principal, si los usuarios seguirían usando la aplicación si se ejecutara en su propia cadena, realmente depende de la compensación entre ese control y la conectividad.

¿Cuánto puede tolerar una aplicación una pérdida de conectividad?

La conectividad se presenta de varias formas. Los dos más importantes son: uno es la atención y el otro es el capital. **

La atención es una atracción natural que viene con ella. Si el proyecto de un equipo es lo primero con lo que un usuario entra en contacto cuando entra en el ecosistema, entonces hay buenas razones para pensar que la aplicación tiene una capacidad nativa para llamar la atención. Las aplicaciones que controlan la atención son más adecuadas para lanzar sus propias cadenas, y los usuarios las usarán independientemente de la cadena en la que exista la aplicación. En mi opinión, algunos ejemplos de aplicaciones que actualmente tienen un atractivo nativo son Mirror, Zora, Manifold, Sound.xyz y OnCyber. También existe el argumento de que las aplicaciones que no tienen una gran capacidad de atracción podrían optar por lanzar sus propias cadenas como un esfuerzo por motivar el interés (aunque no creo que sea muy convincente si muchas cadenas toman esta ruta al mismo tiempo).

El segundo componente de la “conectividad” es el capital. A menudo, el dinero que un usuario despliega para una aplicación se recupera de otra aplicación dentro del mismo ecosistema. Yo lo llamo “movilidad compartida” y su impacto es real. Hemos visto que las nuevas aplicaciones eligen un rollup genérico en lugar de otro porque se conecta más ETH a ese ecosistema. El capital existente dentro del ecosistema puede ayudar a eliminar las barreras para la adopción por parte de los usuarios (en lugar de tratar de convencer a los usuarios de que se conecten a un nuevo ecosistema). Estas consideraciones son relevantes para cualquier aplicación que incorpore alguna forma de financiarización en sus productos. Otros ejemplos que no sean DeFi puros pueden incluir la recopilación de artículos NFT a través de Mirror, el pago para “robar” imágenes en Stealcam o cualquier aplicación que tenga una función de propinas en el producto.

Perder esta “conectividad de capital” significa que la aplicación necesita convencer a los usuarios de que almacenen sus activos futuros en la cadena. Una de las razones podría ser que los consumidores utilizan mucho la aplicación: la conexión entre puentes es dolorosa, por lo que lo más fácil es mantener un suministro adecuado de capital en la cadena. Pero aún más convincente que el inventario inactivo es la opción de proporcionar a los usuarios la generación de ingresos. Esto puede parecer una forma de rendimiento nativo en la cadena, una aplicación que crea un producto adyacente que proporciona rendimiento (como el protocolo de préstamos de Blur) o algo más.

Las razones anteriores (atención y capital) son también razones por las que muchos consideran que los juegos on-chain son candidatos ideales para los rollups específicos de la aplicación: son economías bastante independientes que controlan la cuota psicológica de los consumidores y son importantes para una experiencia de usuario agradable en términos de secuenciación y evitar la congestión. En otras palabras, los juegos on-chain pueden beneficiarse de las cadenas independientes, incluso si están aisladas sin verse gravemente afectadas. Otras aplicaciones que son adecuadas para aplicar acumulaciones pueden minimizar los requisitos de capital inicial del usuario al subsidiar las transacciones (por ejemplo, las primeras transacciones son gratuitas) o no requieren ningún pago en el momento del arranque (por ejemplo, contenido en cadena generado por el usuario, ciertas aplicaciones sociales, redes DePIN, etc.).

Por supuesto, hay otras razones por las que el proyecto quiere tener más control sobre su propia infraestructura. Tener un rollup introduce la capacidad de implementar permisos o hacer cumplir los requisitos de selección de usuarios (por ejemplo, KYC para secuenciadores operados o propiedad de la cadena). Sin embargo, en estos casos, la línea entre los resúmenes y las bases de datos centralizadas es cada vez más difusa.

Minimizar la pérdida de conectividad

A medida que las soluciones de interoperabilidad mejoran, la disyuntiva entre conectividad y control se vuelve menos grave. Los puentes y los secuenciadores suelen ser infraestructuras críticas para el debate en este ámbito. Son similares hasta cierto punto en el sentido de que ambos proporcionan una forma para que las transacciones en una cadena afecten a las transacciones en otra. El puente logra esto mediante el paso de mensajes o la habilitación de transferencias de activos. Los secuenciadores compartidos hacen esto absorbiendo y ordenando transacciones de múltiples cadenas, creando un mecanismo de coordinación que hace que las acciones en una cadena afecten a las acciones en otra. Tanto los secuenciadores compartidos como los puentes son necesarios para la componibilidad atómica: los secuenciadores garantizan la inclusión de múltiples transacciones (entre dominios) en un bloque, y los puentes suelen ser necesarios para ejecutar esas transacciones.

La economía unitaria de los rollups es otra área en la que la “conectividad” ha tenido un impacto significativo. Las tarifas de transacción de capa 2 (L2) se componen de dos partes: 1) el costo de publicar datos de llamada en L1 y 2) el costo pagado por el usuario que se va a incluir. Los operadores de rollup procesan los datos de llamadas de las transacciones en lotes, lo que permite distribuir el costo de publicación entre los usuarios: cuantas más transacciones, menor será el costo promedio por usuario. Esto también significa que los resúmenes con menos actividad pueden retrasar el registro de transacciones en L1 hasta que tengan un lote lo suficientemente grande. La consecuencia son tiempos de finalización más lentos y una peor experiencia de usuario. Parece que los secuenciadores compartidos se están convirtiendo cada vez más en una capa de agregación, donde las transacciones por lotes de varios rollups más pequeños pueden ayudar a crear una economía de unidad viable para la cola larga.

¿Estamos en un punto de inflexión?

El concepto de appchains y app’rollups no es nuevo. Durante mucho tiempo, sin embargo, fue como una zona residencial en desarrollo: se estaba construyendo mucha infraestructura, pero no había habitantes. Pero en los últimos meses, hemos empezado a ver que los primeros residentes llegan poco a poco. Lattice construyó OpCraft, un mundo autónomo en cadena impulsado por su propio Rollup. Proyectos como Lit Protocol y Synapse han anunciado sus propios rollups (aunque ambos son más proyectos de infraestructura que orientados a aplicaciones). Zora lanzó Zorachain. Recientemente, hablé con algunos equipos de aplicaciones maduros, especialmente aquellos que están considerando su estrategia de capa 2, y descubrí que comenzaron a explorar si los paquetes acumulativos de aplicaciones eran adecuados para ellos.

Mi suposición es que el verdadero punto de inflexión llegará en (al menos) 6-12 meses (este artículo se publicó el 30 de junio de 2023). Las aplicaciones de juegos y sociales se combinan más claramente con los resúmenes específicos de la aplicación: tanto las redes sociales como los juegos dependen en gran medida de la indexación (y se benefician enormemente de no tener que competir con el estado compartido), la clasificación es especialmente importante en el juego y las características de personalización, como la ausencia de transacciones de gas, son especialmente útiles para los productos de consumo orientados al entretenimiento. Muchos de estos equipos de aplicaciones aún están en construcción. Los juegos, en particular, pueden tardar años en desarrollarse y lanzarse por completo.

Mi otra conclusión es que para las aplicaciones menos financiarizadas, tener atención es el factor más crítico. Hasta ahora, este artículo ha enmarcado los paquetes acumulativos de aplicaciones como “una aplicación por paquete acumulativo”. Pero este punto de vista puede ser demasiado estrecho. Tal vez varias aplicaciones decidan formar un colectivo, unan su “atención” y lancen una cadena juntas. Del mismo modo, es posible que veamos que una aplicación importante decide crear su propia cadena y animar a otras aplicaciones a desplegarse en ella, es decir, aprovechar su propia aplicación para practicar la adopción de la infraestructura que quiere controlar.

Por último, creo que veremos más rollups en el futuro. Ha habido una explosión de proyectos para construir servicios de infraestructura para la aplicación de rollups. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer y más proporcionan una solución de baja barrera para que los equipos lancen rápidamente sus propios rollups. SUAVE para Espresso, Astria y Flashbots fueron los primeros en entrar en el espacio de los secuenciadores. Los costos de construcción están disminuyendo y la gravedad de la disyuntiva de “conectividad” está disminuyendo. Ambos puntos refuerzan los argumentos a favor de la adopción. Sin embargo, la aparición de un gran número de nuevos proveedores de infraestructura también significa que los equipos de aplicaciones pueden tomarse el tiempo necesario para comprender las distintas opciones y someter a estos diferentes actores a la batalla antes de elegir un ganador. Así que, aunque las señales apuntan en la dirección de la adopción, creo que el verdadero punto de inflexión aún está a unos meses de distancia.