Escrito por: Alana Levin; Compilado por: Luffy, Foresight News
Hace dos años, los desarrolladores de aplicaciones se enfrentaron a una elección bastante simple al decidir en qué cadena implementar su aplicación: Ethereum, Solana, Cosmos u otra cadena de bloques de capa 1. En ese momento, Rollup aún no había lanzado la red principal y pocas personas habían oído hablar del término "pila modular". Las diferencias entre los L1 (rendimiento, tarifas, etc.) son obvias y relativamente fáciles de entender.
Las cosas se ven muy diferentes hoy. Los desarrolladores de aplicaciones se enfrentan a más opciones: L1, resumen de propósito general (Optimistic y zk), infraestructura IBC, proveedor de resumen como servicio, AppChain y más. Más opciones generan más preguntas: ¿deberían los equipos implementar aplicaciones en resúmenes genéricos o crear resúmenes específicos de aplicaciones? Si van por el paquete acumulativo genérico, cuál elegir, si van por la ruta del paquete acumulativo de aplicaciones, qué SDK/paquete acumulativo como servicio usar, qué capa de disponibilidad de datos elegir, puede ayudar EigenLayer, cómo pensar en los secuenciadores; si eligen Tomar la ruta de OP Stack, si puede ocupar un lugar en el ecosistema de la súper cadena de Optimism.
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. Como tal, este artículo se centrará en el árbol de decisiones que enfrentan los equipos de aplicaciones cuando deciden lanzar su propio paquete acumulativo, qué tipos de aplicaciones son particularmente adecuadas para ciertos tipos de infraestructura y cuándo creo que podemos llegar a un punto de inflexión para la adopción.
Marco de Alto Nivel
En el corazón de la decisión de acumulación de aplicaciones, en realidad hay una pregunta simple: si la aplicación se creara en su propia cadena, ¿los usuarios la seguirían usando? Un mayor desarrollo son dos preguntas:
¿Es más probable que los usuarios usen una aplicación si está en su propia cadena?
Si la aplicación está en su propia cadena, ¿la usarán los usuarios también?
Los beneficios de los rollups específicos de la aplicación son un mejor control: la capacidad de abstraer los costos de la 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 (por ejemplo, reembolsos de gasolina), construir Personalizar el entorno de ejecución, implementar controles de acceso (como la implementación de permisos) y más.
Pero el precio de este control adicional es una pérdida de conectividad con el ecosistema más amplio. Las aplicaciones en una cadena universal tienen acceso a la liquidez que ya está en esa cadena (por ejemplo, no se necesitan puentes adicionales entre cadenas), compatibilidad con otras aplicaciones y atención al usuario en la cadena. En comparación con las aplicaciones que ejecutan sus propias cadenas, construir sobre la cadena general también ahorra muchos gastos generales de ingeniería.
Un mejor control podría 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 esta compensación de control versus conectividad.
**¿Cuánta conectividad puede sacrificar una aplicación? **
Las conexiones vienen en muchas formas, las dos más importantes son: 1) atención y 2) capital.
La atención está relacionada con la comunicación nativa. Si el proyecto de un equipo es el primer proyecto con el que los usuarios interactúan cuando ingresan al ecosistema, entonces la aplicación es viral de forma nativa. Las aplicaciones que pueden llamar la atención son más adecuadas para lanzar su propia cadena; los usuarios usarán la aplicación sin importar en qué cadena se encuentre. En mi opinión, las aplicaciones actuales con propagación nativa incluyen Mirror, Zora, Manifold, Sound.xyz y OnCyber. También existe el argumento de que las aplicaciones sin una fuerte difusión pueden optar por lanzar sus propias cadenas para despertar el interés de los usuarios (pero me parece menos convincente si muchas cadenas siguen esta ruta al mismo tiempo).
La segunda forma de conectividad es el capital. A menudo, los fondos que los usuarios implementan en una aplicación se transfieren desde otra aplicación en el mismo ecosistema. Yo lo llamo "liquidez compartida" y sus implicaciones son reales. Una gran cantidad de aplicaciones nuevas eligen Universal Rollup debido a la gran cantidad de ETH conectada a este ecosistema, y 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 para que ingresen a un nuevo ecosistema). Estos factores son consideraciones para cualquier aplicación que incorpore alguna forma de financiarización en su producto. Los ejemplos fuera de DeFi pueden incluir: recopilar documentos 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.
Perder esta "conectividad de fondos" significa que las aplicaciones deben obligar a los usuarios a estacionar fondos en la cadena. Una razón podría ser que los consumidores usan mucho la aplicación, después de todo, las cadenas cruzadas son dolorosas, por lo que sería más fácil mantener un suministro saludable de fondos en la cadena. Pero aún más convincente que los fondos inactivos es dar a los usuarios la opción de generar rendimiento. Esto parece rendimiento en forma de cadenas nativas, aplicaciones que crean productos adyacentes que brindan rendimiento (como el protocolo de préstamos de Blur) y más.
La atención y el capital también son la razón por la que muchos ven los juegos en cadena como candidatos ideales para acumulaciones específicas de aplicaciones: son economías bastante independientes y dependen en gran medida de una experiencia de usuario fluida. En otras palabras, los juegos en cadena se benefician de un alto grado de control y no sufren pérdidas significativas si quedan huérfanos. Otras aplicaciones que son adecuadas para Rollup pueden hacerlo subsidiando las transacciones (p. ej., las primeras transacciones son gratuitas) o no requieren pago al iniciar sesión (p. ej., contenido en cadena generado por el usuario, ciertas aplicaciones sociales, redes DePIN, etc.) Minimiza 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. Los paquetes acumulativos patentados permiten la capacidad de implementar permisos y evaluar a los usuarios (por ejemplo, KYC para secuenciadores operados/propiedad de la cadena). Sin embargo, esto también conduce a que se difumine la línea entre las bases de datos acumuladas y las bases de datos centralizadas.
Minimizar la pérdida de conectividad
A medida que mejoran las soluciones de interoperabilidad, la compensación entre conectividad y control se vuelve menos importante. Los puentes y los secuenciadores son a menudo la infraestructura crítica que se analiza. 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, los ordenadores compartidos lo hacen al ingerir y ordenar transacciones de múltiples cadenas. Tanto los ordenadores compartidos como los puentes son necesarios para la compatibilidad atómica: se garantiza que el ordenante contenga múltiples transacciones (entre cadenas) en un bloque, y la ejecución real de estas transacciones generalmente requiere un puente.
La economía de la unidad de Rollups es otra área donde la "conectividad" tiene un impacto. Las tarifas de transacción de L2 constan de dos partes: 1) el costo de publicar datos en L1 y 2) el costo que pagan los usuarios por la transacción. Rollup procesa datos de llamadas de transacciones por lotes para que el costo de publicación se pueda compartir entre los usuarios: cuantas más transacciones, menor es el costo promedio por usuario. Esto también significa que los paquetes acumulativos menos activos pueden retrasar la publicación de transacciones en L1 hasta que tengan un paquete de transacciones lo suficientemente grande. La consecuencia son tiempos de finalización más lentos y una experiencia de usuario deficiente. 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 unidades económicas viables para individuos de cola larga.
**¿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 sin residentes. En los últimos meses, hemos comenzado a ver una afluencia de primeros residentes. Lattice construyó OpCraft, un mundo autónomo en cadena respaldado por su propio paquete acumulativo; Lit Protocol y Synapse han anunciado su propio paquete acumulativo (aunque ambos están más orientados a la infraestructura que a proyectos orientados a aplicaciones); Zora lanzó Zorachain. Conversaciones recientes con equipos de aplicaciones maduros (especialmente aquellos que consideran estrategias L2) han comenzado a explorar si los paquetes acumulativos de aplicaciones son adecuados 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 mercado de productos más obvio con los paquetes acumulativos específicos de aplicaciones: tanto las redes sociales como los juegos dependen en gran medida de la indexación, los problemas de pedidos (especialmente en el juego) y las características personalizadas (como transacciones sin gasolina) para el consumo recreativo. Los productos son muy importante. Muchos equipos de aplicaciones están en construcción, especialmente juegos, que pueden tardar años en desarrollarse y lanzarse.
Mi otra conclusión es que para las aplicaciones menos financieras, lo más importante es llamar la atención. 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. Quizás haya múltiples aplicaciones formando un colectivo para iniciar una cadena juntos. Del mismo modo, podemos ver una aplicación construir su propia cadena y animar a otras aplicaciones a implementarse encima de ella.
Finalmente, creo firmemente que veremos más Rollups en el futuro. Proliferarán los proyectos que construyan servicios de infraestructura para acumulaciones de aplicaciones. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. brindan a los equipos de aplicaciones soluciones de bajo umbral para iniciar su propio resumen. Espresso, Astria y SUAVE de Flashbots fueron algunos de los primeros exploradores en el espacio de los secuenciadores. Los costos de puesta en marcha tienen una tendencia a la baja y la compensación de "conectividad" se vuelve menos importante. Pero una cantidad tan grande de nuevos proveedores de infraestructura también significa que los equipos de aplicaciones pueden tomar tiempo para comprender las diversas opciones, y estallará una guerra entre estos jugadores. Nuevamente, si bien hay signos de adopción, creo que el punto de inflexión aún está a unos meses de distancia.
Gracias a Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer y Viktor Bunin por sus comentarios, comentarios y conversaciones que ayudaron a desarrollar muchas de estas ideas.
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.
Bajo la tendencia de la modularización, ¿debería la aplicación construir su propia cadena?
Escrito por: Alana Levin; Compilado por: Luffy, Foresight News
Hace dos años, los desarrolladores de aplicaciones se enfrentaron a una elección bastante simple al decidir en qué cadena implementar su aplicación: Ethereum, Solana, Cosmos u otra cadena de bloques de capa 1. En ese momento, Rollup aún no había lanzado la red principal y pocas personas habían oído hablar del término "pila modular". Las diferencias entre los L1 (rendimiento, tarifas, etc.) son obvias y relativamente fáciles de entender.
Las cosas se ven muy diferentes hoy. Los desarrolladores de aplicaciones se enfrentan a más opciones: L1, resumen de propósito general (Optimistic y zk), infraestructura IBC, proveedor de resumen como servicio, AppChain y más. Más opciones generan más preguntas: ¿deberían los equipos implementar aplicaciones en resúmenes genéricos o crear resúmenes específicos de aplicaciones? Si van por el paquete acumulativo genérico, cuál elegir, si van por la ruta del paquete acumulativo de aplicaciones, qué SDK/paquete acumulativo como servicio usar, qué capa de disponibilidad de datos elegir, puede ayudar EigenLayer, cómo pensar en los secuenciadores; si eligen Tomar la ruta de OP Stack, si puede ocupar un lugar en el ecosistema de la súper cadena de Optimism.
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. Como tal, este artículo se centrará en el árbol de decisiones que enfrentan los equipos de aplicaciones cuando deciden lanzar su propio paquete acumulativo, qué tipos de aplicaciones son particularmente adecuadas para ciertos tipos de infraestructura y cuándo creo que podemos llegar a un punto de inflexión para la adopción.
Marco de Alto Nivel
En el corazón de la decisión de acumulación de aplicaciones, en realidad hay una pregunta simple: si la aplicación se creara en su propia cadena, ¿los usuarios la seguirían usando? Un mayor desarrollo son dos preguntas:
Los beneficios de los rollups específicos de la aplicación son un mejor control: la capacidad de abstraer los costos de la 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 (por ejemplo, reembolsos de gasolina), construir Personalizar el entorno de ejecución, implementar controles de acceso (como la implementación de permisos) y más.
Pero el precio de este control adicional es una pérdida de conectividad con el ecosistema más amplio. Las aplicaciones en una cadena universal tienen acceso a la liquidez que ya está en esa cadena (por ejemplo, no se necesitan puentes adicionales entre cadenas), compatibilidad con otras aplicaciones y atención al usuario en la cadena. En comparación con las aplicaciones que ejecutan sus propias cadenas, construir sobre la cadena general también ahorra muchos gastos generales de ingeniería.
Un mejor control podría 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 esta compensación de control versus conectividad.
**¿Cuánta conectividad puede sacrificar una aplicación? **
Las conexiones vienen en muchas formas, las dos más importantes son: 1) atención y 2) capital.
La atención está relacionada con la comunicación nativa. Si el proyecto de un equipo es el primer proyecto con el que los usuarios interactúan cuando ingresan al ecosistema, entonces la aplicación es viral de forma nativa. Las aplicaciones que pueden llamar la atención son más adecuadas para lanzar su propia cadena; los usuarios usarán la aplicación sin importar en qué cadena se encuentre. En mi opinión, las aplicaciones actuales con propagación nativa incluyen Mirror, Zora, Manifold, Sound.xyz y OnCyber. También existe el argumento de que las aplicaciones sin una fuerte difusión pueden optar por lanzar sus propias cadenas para despertar el interés de los usuarios (pero me parece menos convincente si muchas cadenas siguen esta ruta al mismo tiempo).
La segunda forma de conectividad es el capital. A menudo, los fondos que los usuarios implementan en una aplicación se transfieren desde otra aplicación en el mismo ecosistema. Yo lo llamo "liquidez compartida" y sus implicaciones son reales. Una gran cantidad de aplicaciones nuevas eligen Universal Rollup debido a la gran cantidad de ETH conectada a este ecosistema, y 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 para que ingresen a un nuevo ecosistema). Estos factores son consideraciones para cualquier aplicación que incorpore alguna forma de financiarización en su producto. Los ejemplos fuera de DeFi pueden incluir: recopilar documentos 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.
Perder esta "conectividad de fondos" significa que las aplicaciones deben obligar a los usuarios a estacionar fondos en la cadena. Una razón podría ser que los consumidores usan mucho la aplicación, después de todo, las cadenas cruzadas son dolorosas, por lo que sería más fácil mantener un suministro saludable de fondos en la cadena. Pero aún más convincente que los fondos inactivos es dar a los usuarios la opción de generar rendimiento. Esto parece rendimiento en forma de cadenas nativas, aplicaciones que crean productos adyacentes que brindan rendimiento (como el protocolo de préstamos de Blur) y más.
La atención y el capital también son la razón por la que muchos ven los juegos en cadena como candidatos ideales para acumulaciones específicas de aplicaciones: son economías bastante independientes y dependen en gran medida de una experiencia de usuario fluida. En otras palabras, los juegos en cadena se benefician de un alto grado de control y no sufren pérdidas significativas si quedan huérfanos. Otras aplicaciones que son adecuadas para Rollup pueden hacerlo subsidiando las transacciones (p. ej., las primeras transacciones son gratuitas) o no requieren pago al iniciar sesión (p. ej., contenido en cadena generado por el usuario, ciertas aplicaciones sociales, redes DePIN, etc.) Minimiza 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. Los paquetes acumulativos patentados permiten la capacidad de implementar permisos y evaluar a los usuarios (por ejemplo, KYC para secuenciadores operados/propiedad de la cadena). Sin embargo, esto también conduce a que se difumine la línea entre las bases de datos acumuladas y las bases de datos centralizadas.
Minimizar la pérdida de conectividad
A medida que mejoran las soluciones de interoperabilidad, la compensación entre conectividad y control se vuelve menos importante. Los puentes y los secuenciadores son a menudo la infraestructura crítica que se analiza. 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, los ordenadores compartidos lo hacen al ingerir y ordenar transacciones de múltiples cadenas. Tanto los ordenadores compartidos como los puentes son necesarios para la compatibilidad atómica: se garantiza que el ordenante contenga múltiples transacciones (entre cadenas) en un bloque, y la ejecución real de estas transacciones generalmente requiere un puente.
La economía de la unidad de Rollups es otra área donde la "conectividad" tiene un impacto. Las tarifas de transacción de L2 constan de dos partes: 1) el costo de publicar datos en L1 y 2) el costo que pagan los usuarios por la transacción. Rollup procesa datos de llamadas de transacciones por lotes para que el costo de publicación se pueda compartir entre los usuarios: cuantas más transacciones, menor es el costo promedio por usuario. Esto también significa que los paquetes acumulativos menos activos pueden retrasar la publicación de transacciones en L1 hasta que tengan un paquete de transacciones lo suficientemente grande. La consecuencia son tiempos de finalización más lentos y una experiencia de usuario deficiente. 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 unidades económicas viables para individuos de cola larga.
**¿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 sin residentes. En los últimos meses, hemos comenzado a ver una afluencia de primeros residentes. Lattice construyó OpCraft, un mundo autónomo en cadena respaldado por su propio paquete acumulativo; Lit Protocol y Synapse han anunciado su propio paquete acumulativo (aunque ambos están más orientados a la infraestructura que a proyectos orientados a aplicaciones); Zora lanzó Zorachain. Conversaciones recientes con equipos de aplicaciones maduros (especialmente aquellos que consideran estrategias L2) han comenzado a explorar si los paquetes acumulativos de aplicaciones son adecuados 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 mercado de productos más obvio con los paquetes acumulativos específicos de aplicaciones: tanto las redes sociales como los juegos dependen en gran medida de la indexación, los problemas de pedidos (especialmente en el juego) y las características personalizadas (como transacciones sin gasolina) para el consumo recreativo. Los productos son muy importante. Muchos equipos de aplicaciones están en construcción, especialmente juegos, que pueden tardar años en desarrollarse y lanzarse.
Mi otra conclusión es que para las aplicaciones menos financieras, lo más importante es llamar la atención. 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. Quizás haya múltiples aplicaciones formando un colectivo para iniciar una cadena juntos. Del mismo modo, podemos ver una aplicación construir su propia cadena y animar a otras aplicaciones a implementarse encima de ella.
Finalmente, creo firmemente que veremos más Rollups en el futuro. Proliferarán los proyectos que construyan servicios de infraestructura para acumulaciones de aplicaciones. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. brindan a los equipos de aplicaciones soluciones de bajo umbral para iniciar su propio resumen. Espresso, Astria y SUAVE de Flashbots fueron algunos de los primeros exploradores en el espacio de los secuenciadores. Los costos de puesta en marcha tienen una tendencia a la baja y la compensación de "conectividad" se vuelve menos importante. Pero una cantidad tan grande de nuevos proveedores de infraestructura también significa que los equipos de aplicaciones pueden tomar tiempo para comprender las diversas opciones, y estallará una guerra entre estos jugadores. Nuevamente, si bien hay signos de adopción, creo que el punto de inflexión aún está a unos meses de distancia.
Gracias a Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer y Viktor Bunin por sus comentarios, comentarios y conversaciones que ayudaron a desarrollar muchas de estas ideas.