¿De dónde vienen los efectos de red L2? ¿Qué hace que L2 sea pegajoso?

Autor: Alana Levin; Compilador: Huohuo, blockchain vernáculo

Hace dos años, los desarrolladores de aplicaciones se enfrentaron a una elección bastante simple al decidir dónde implementar sus aplicaciones: Ethereum, Solana, Cosmos o quizás alguna otra cadena de capa 1. Rollup aún no está en uso y pocas personas han escuchado el término "pila modular". Las diferencias entre L1 (rendimiento, costo, etc.) son obvias y relativamente fáciles de comprender.

** Las cosas se ven muy diferentes hoy. Los desarrolladores de aplicaciones se enfrentan a más opciones: L1, resúmenes genéricos (Optimistic y zk), infraestructura IBC avanzada, proveedores de resúmenes como servicio, cadenas de aplicaciones y más. **

Más opciones generan más preguntas, que incluyen: ¿deberían los equipos implementar paquetes acumulativos genéricos o crear paquetes acumulativos específicos de la aplicación? Si elige rollup general, ¿cuál elegir? Si optan por la implementación de la aplicación, ¿qué SDK/resumen como servicio usar? ¿Qué nivel de disponibilidad de datos elegir? ¿Puede EigenLayer ayudar? ¿Cómo pensar en los secuenciadores? Si eligen seguir la ruta OP Stack, ¿quedará un emoji de esfera colorida en el ecosistema de supercadena de Optimism? Estas preguntas son engañosas.

Para reducir el problema, este artículo adoptará el marco de una aplicación ya implementada en Ethereum que desea escalar dentro del ecosistema de Ethereum. Por lo tanto, la atención se centrará en el árbol de decisiones que enfrentan los equipos de aplicaciones para determinar si lanzar su propio paquete acumulativo, las suposiciones sobre qué tipos de aplicaciones son particularmente adecuadas para esta infraestructura y cuándo creo que podríamos llegar a un punto de inflexión para la adopción.

1. Marco de alto nivel

En el corazón de la decisión de resumen de una aplicación, en realidad hay una pregunta simple: **si la aplicación estuviera en su propia cadena, ¿los usuarios seguirían usándola? **Hay dos subconjuntos de esta pregunta:

1) ¿Es más probable que los usuarios usen una aplicación si está en su propia cadena?

2) Si la aplicación está en su propia cadena, ¿es igualmente posible que el usuario use la aplicación?

Los beneficios acumulativos específicos de la aplicación provienen de un mayor control: Capacidad para extraer costos de gasolina, limitar la congestión en la cadena causada por otra actividad de la aplicación, experimentar mejor cómo se utilizan los tokens, explorar diferentes estructuras económicas (como reembolsos de gasolina integrados) , cree entornos de ejecución personalizados, implemente controles de acceso (como la implementación de permisos) y más.

** Pero este control adicional tiene el costo de la conectividad con el ecosistema más grande. **Las aplicaciones en una cadena compartida/universal tienen acceso a la liquidez que ya está en esa cadena (p. ej., sin puentes adicionales entre cadenas), compatibilidad con otras aplicaciones y usuarios que ya están dedicados a la atención de esa cadena. Construir sobre una cadena común también requiere menos trabajo/gastos generales de ingeniería internos que una aplicación que ejecuta su propia cadena.

Mejores controles podrían mejorar la experiencia del usuario si fuera gratis. Entonces, la respuesta a la pregunta central, si los usuarios seguirían usando una aplicación si estuviera en su propia cadena, realmente depende de qué tan severa sea esta compensación entre el control y la conexión. **

2. ¿Cuántas conexiones se puede permitir perder la aplicación?

Las conexiones vienen en muchas formas. Los dos más importantes son: 1) Atención, y 2) Capital.

** Tenga en cuenta la distribución nativa. Si el proyecto del equipo es lo primero con lo que los usuarios se involucran cuando ingresan al ecosistema, es un caso convincente para que la aplicación tenga una distribución nativa. ** Las aplicaciones para controlar la atención son más adecuadas para iniciar su propia cadena; el usuario usará esa aplicación independientemente de la cadena en la que se encuentre. En mi opinión, los ejemplos actuales de aplicaciones que tienen una distribución nativa incluyen Mirror, Zora, Manifold, Sound.xyz y OnCyber. También existe el argumento de que las aplicaciones sin una distribución sólida pueden optar por lanzar sus propias cadenas para despertar el interés.

El segundo componente de la "conectividad" es el capital. A menudo, los fondos desplegados por los usuarios para una aplicación se recuperan de otra aplicación en el mismo ecosistema. Yo lo llamo "liquidez compartida" y sus implicaciones son reales. Hemos visto aplicaciones nuevas que eligen un paquete acumulativo de uso general en lugar de otro debido a la mayor cantidad de ETH conectada al ecosistema; el capital existente dentro del ecosistema puede ayudar a eliminar las barreras para la adopción de los usuarios (en lugar de tratar de convencer a los usuarios de que ingresen a un nuevo ecosistema). Estas consideraciones son relevantes para cualquier aplicación que incorpore alguna forma de financiarización en su producto. Los ejemplos fuera de DeFi puro podrían incluir la recopilación de artículos NFT a través de Mirror, pagar para "robar" imágenes en una Stealcam o cualquier cosa con una función de propinas en el producto.

**La pérdida de esta "conectividad de fondos" significa que las aplicaciones deben obligar a los usuarios a estacionar su inventario en la cadena. ** Una razón puede ser que los consumidores usan mucho la aplicación: la experiencia de conexión es dolorosa, por lo que será más fácil mantener un suministro saludable de fondos en la cadena. Pero incluso más convincente que el inventario inactivo es ofrecer a los usuarios opciones que generen ingresos. Esto podría parecer una forma de rendimiento nativa de 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) también explican por qué muchos ven los juegos en cadena como candidatos ideales para rollups específicos de aplicaciones: son economías bastante autónomas, controlan la participación mental de los consumidores y son una forma de sortear y evitar la congestión. es una categoría que es importante para una experiencia de usuario agradable.

En otras palabras, los juegos en cadena se benefician de un alto grado de control y no se ven afectados significativamente si están aislados. Otras aplicaciones que son adecuadas para la acumulación de aplicaciones pueden hacerlo subsidiando las transacciones (p. ej., las primeras transacciones son gratuitas) o no requieren ningún pago al principio (p. ej., contenido en cadena generado por el usuario, ciertas aplicaciones sociales, redes DePIN, etc.) Minimizar los requisitos iniciales de capital de usuario.

Por supuesto, hay otras razones por las que los proyectos quieren tener más control sobre su infraestructura. Tener un paquete acumulativo introduce permiso para implementar o la capacidad de implementar requisitos de detección de usuarios (como KYC en secuenciadores operados/propiedad de la cadena). En estos casos, sin embargo, la línea entre las bases de datos acumuladas y las bases de datos centralizadas se vuelve cada vez menos clara.

3. Minimiza la pérdida de conexión

A medida que mejoran las soluciones de interoperabilidad, la compensación entre conectividad y control se vuelve menos crítica. **Los puentes y los secuenciadores suelen ser la infraestructura crítica que se analiza en esta pregunta. Son algo similares en el sentido de que ambos proporcionan una forma para que las transacciones en una cadena afecten las transacciones en otra cadena. **Los puentes hacen esto pasando mensajes o habilitando transferencias de activos. Un ordenante compartido hace esto al ingerir y ordenar transacciones de múltiples cadenas, creando un mecanismo de coordinación que permite que las acciones en una cadena afecten las acciones en otra. La componibilidad atómica requiere secuenciadores y puentes compartidos: se garantiza que el secuenciador contenga múltiples transacciones (entre dominios) en un bloque, y la ejecución real de estas transacciones generalmente requiere un puente.

La economía unitaria de los Rollups es otra área donde la "conectividad" tiene un impacto. **Las tarifas de transacción de L2 se componen de dos factores: 1) el costo de publicar datos en L1 y 2) el costo que pagan los usuarios por su inclusión. **El operador acumula datos de llamadas por lotes para las transacciones, lo que permite que los costos de publicación se distribuyan entre los usuarios: cuantas más transacciones, menor es el costo promedio por usuario. Esto también significa que los rollups menos activos pueden retrasar la publicación de transacciones en L1 hasta que tengan un tamaño de lote lo suficientemente grande. La consecuencia es un tiempo de finalización más lento y una peor experiencia de usuario. Los pedidos compartidos parecen estar sirviendo cada vez más como capas de agregación, donde las transacciones por lotes de múltiples acumulaciones más pequeñas pueden ayudar a crear una unidad económica viable para la existencia de la cola larga.

4. ¿Estamos en un punto de inflexión?

La idea de cadenas de aplicaciones y acumulaciones de aplicaciones no es nueva. Sin embargo, durante mucho tiempo se sintió como un área residencial en desarrollo: se estaba construyendo mucha infraestructura, pero no había residentes.

Pero en los últimos meses, hemos comenzado a ver la primera afluencia de residentes. Lattice creó OpCraft, un mundo autónomo en cadena respaldado por su propio paquete acumulativo. Proyectos como Lit Protocol y Synapse han anunciado sus propios paquetes acumulativos (aunque ambos están más orientados a la infraestructura que a la aplicación). Zora lanzó Zorachain. Conversaciones recientes con equipos de capa de aplicación más maduros (especialmente aquellos que consideran estrategias L2) han comenzado a explorar si la acumulación de aplicaciones es adecuada para ellos.

Mi suposición es que el punto de inflexión real llegará en (al menos) 6-12 meses. ** Las aplicaciones sociales y de juegos tienen el ajuste de producto-mercado más obvio con acumulaciones específicas de aplicaciones: las redes sociales y los juegos dependen en gran medida de la indexación (y se benefician enormemente al no tener que competir con el estado compartido), los problemas de pedido (especialmente en el juego) y Las funciones personalizadas (como transacciones sin gas) son especialmente útiles para productos de consumo orientados al entretenimiento**. Muchos de estos equipos de aplicación aún están en construcción. Los juegos, en particular, pueden tardar años en desarrollarse y lanzarse.

Mi otra conclusión es que llamar la atención es el factor más crítico para las aplicaciones menos financieras. Hasta ahora, este artículo ha definido los paquetes acumulativos de aplicaciones como "una aplicación por paquete acumulativo". Pero esta visión puede ser demasiado estrecha. Tal vez varias aplicaciones decidan formar un colectivo, juntar su "atención" y comenzar una cadena juntas. Del mismo modo, podemos ver que una aplicación importante decide construir su propia cadena y alentar a otras aplicaciones a implementarla; de hecho, usa su propia aplicación para probar la adopción de la infraestructura que desea controlar.

Finalmente, creo firmemente que veremos más acumulaciones en el futuro. Ha habido una proliferación de proyectos que construyen servicios de infraestructura para acumulaciones de aplicaciones. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. brindan soluciones de poca elevación para que los equipos comiencen su propio resumen.

Espresso, Astria y SUAVE de Flashbots son algunos de los primeros participantes en el espacio de los secuenciadores. Los costos de instalación tienen una tendencia a la baja y la compensación de "conectividad" se vuelve menos severa. Ambos refuerzan el caso de la adopción. **Pero una cantidad tan grande de nuevos proveedores de infraestructura también significa que los equipos de aplicaciones pueden tomarse el tiempo para comprender las diversas opciones y poner a prueba a estos diversos jugadores antes de elegir un ganador. ** Nuevamente, si bien hay signos de adopción, creo que el punto de inflexión aún está a unos meses de distancia.